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IMTRODPCTIQH 



Data laBageEent: is a general tera that 
collectively describes the functions of the 
controlling system routines that provide 
access to data sets, enforce data storage 
conventions, and regulate the use of input/ 
output devices. The data manageaent facil- 
ities of TSS: 

Permit the user to store , aodify, and 
refer to programs and data, using the 
system storage facilities. 

Free the user from concern with specific 
input/output device configurations. 

Fermit the user to defer such specifica- 
tions as device type and length of rec- 
ords in the data set, until a program is 
submitted for execution. 



Provide the flexibility for including 
new or improved devices, as they become 
available. 



Provide comprehensive error-recovery 
procedures. 



To most efficiently employ these facil- 
ities for his own purposes, the user of TSS 
should have a clear idea of those that are 
available to him, and a general idea of how 
they operate. This manual provides a suf- 
ficiently detailed description of the sys- 
tem's data management facilities to serve 
this need, without descending to a level of 
detail that would destroy the overall pic- 
ture of these services. 



Permit any desired interchange of pro- 
grams and data among TSS installations - 

Save the time and expense involved in 
writing routines similar to those pro- 
vided by IBM. 

Allow users to concentrate their pro- 
gramming efforts on processing the rec- 
ords read and written by the data man- 
agement f uncrtions . 

Provide standardized methods for han- 
dling a wide range of input/output and 
related operations. 



Part I consists of descriptions of some 
introductory concepts necessary for a dis- 
cussion of data management. 



Part II describes how data management is 
effected in TSS, at its basic level. 



Part III shows how higher-level, user- 
oriented services interact with the basic 
data management facilities, to perform a 
broader range of duties. 
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PIST I: 



BASIC COlCEPfS OF DATI HAIAGEIEIT 



I record is a col 
items, treated as a 
ing^ a record is rar 
cessed individually, 
treated in structure 
coMectioBS, called 
may be^ for example, 
library of nacro ins 
data records to be p 
prograB« In general 
grouped as data sets 
to procDess tliem coll 



lection of related data 
unit. In data process- 
ely considered or pro- 

lormally, records are 
dr logically related 
data sets , 1 data set 

a source program ,. a 
tructions, or a file of 
rocessed by a problem 
, data records are 

because of some need 
ectively. 



1AMIM6 AMD CATALQGIIG DATA SETS 



Wben a user wants 
data sety he require 
fying to the system 
be is concerned with 

cipal data aanageaen 
designed to free the 
ations of data set r 
that responsibility 
ttany data sets are n 
entities J. and may oo 
tered portions. For 
set specification by 
general rule; rather 
vide an interface th 
user's logical sped 
to that data set*s p 



to create or access a 
s soae neans of speci-- 
the particular data set 
Under TSS, the prin- 
t routines have been 

user from consider- 
esidencei^ and delegate 
to the systea ; also^ 
ot physically connected 
nsist of widely scat- 

these reasons^ data 

location cannot be the 
g the systea must pro- 
at will relate the 
fication of a data set 
hysical location. 



For direct access voluaesr the system 
catalog serves to relate the user's speci- 
fication of a data set — the data set*s 
name — to a description of its physical 
structure, specified in a data set control 
block fBSCB) . For tape volumes^ the cata- 
log links the name to the beginning of the 
data set on the appropriate volume. In 
designing the data set naming structure^ 
one consideration was the sharing of data 
sets permitted under the TSS data manage- 
ment facilities. This sharing is imple- 
mented through the catalog; also^ it is de- 
sirable to enable users to permit or 
restrict a sharer *s access to a data set 
collection^ rather than individually data 
set by data set. Example: If a user has a 
collection of data sets concerned with one 
project and wants to grant other users 
access. to his entire collection^ it will be 
easier for him and more efficient for the 
system to specify his group by one name. 
The user implies a data set hierarchy by 
specifying only a data set name; the speci 
fication of the upper portion of a hierar- 
chy includes all the data sets logically 
below it. 



Within TSS,- a data set name is a series 
of one or more simple names, called com- 
ponents, joined so that each represents a 
level of qualification. Example: The data 
set name BEC01DS.PEBSONEL.DEPT561 consists 
of three components, delimited by periods; 
each component represents a unique cate- 
gory , within which the next component is a 
unique subcategory. In this example, some 
individuals might be permitted to access 
all records of the company, denoted by the 
partially qualified data set name BECOHDS ; 
others might be permitted to access all the 
personnel records of the company, denoted 
by the partially qualified data set name 
BECOBDS.FERSOllL; some might be permitted 
access to only the personnel records of a 
particular department, 
RECOBDS . PEBSOHEL . DEPT56 1 . 



A fully qualified data set name identi- 
fies an individual data set and includes 
all components of that data set's name. In 
the preceding example, the personnel rec- 
ords of Department 561 were uniquely iden- 
tified by the fully qualified data set name 
BECORDS.PEBSONBL.DEPT561. A partially 
qualified data set name identifies a group 
of data sets, and omits one or more of the 
right-most components of a data set name. 
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Figure 1 . Fully and partially qualified 
names 



In one exanple^ all records of the co^panj 
are designated bj the partially qualified 
data set name BECOIDS, and all the person- 
nel records by the partially qualified data 
set name EECORDS .PSSS08BL (see Figure 1). 

These rules Must be observed in naming 
data sets: 



1. 



2. 



3. 



4. 



Bach component except the last must 
consist of from one to eight alphaaer- 
ic characters Cthis is why '•person- 
nel'*^ in the example and Figure 1, has 
only one N) ; the first charact€ir must 
be alphabetic. 

The last component can consist of ei- 
ther alphameric characters, as in rule 
1, or a relative generation number. I 
relative generation number consists of 
a signed integer in parentheses. Ex- 
ample: PAYROLL .CIEIKS (-1) . The sys- 
tem treats each relative generation 
number as the equivalent of an abso- 
lute generation number, which has the 
form GxxxxVyy, where xxxx is an 
unsigned four-digit integer and yy is 
an unsigned two-digit integer. Use of 
a generation number leaves a maximum 
of 26 characters available for higher- 
level qualification of the name. 
(Data sets cataloged under the same 
name but different generation numbers 
are generations of a generation data 
crronp > which avoids the necessity of 
giving a unique name to each data set. 
For more how-to information on genera- 
tion data groups, see Concepts and Fa- 
cilities , C ommand System Pser^s Guide , 
Assembler Proqprammer 's Guide , FQRTBAH 
Procrrammer' s Guide , or PL/I CF| Pro- 
crrammer's Guide . I 

I period must be used to separate 
components. 



For data sets u 
TSS, the user i 
ters, because t 
prefixes each n 
character user 
od. The maximu 
(including peri 
is 44. For dat 
changed with th 
user can employ 
names. These d 
not be cataloge 
renamed. 



sed exclusively within 
s limited to 35 charac- 
he system automatically 
ame with his eight 
ID, followed by a peri- 
m number of characters 
ods) in a data set name 
a sets to be inter- 
e Operating System, the 

44 character data set 
at a sets, however, can- 
d in TSS without being 



The maximum number of single-character 
qualification levels for a basic name 
is 18, for data sets used in TSS. 
Sormally, fewer qualification levels 
will be used. 



unicrue : no fully qualified data set 
name can be used as a partial qualifi- 
er for another fully qualified data 
set name. 



Figure 2 illustrates how data sets on 
direcrt access volumes are located by data 
set name, under the system catalog concept. 
The system catalog is organized into a 
hierarchy of indexes, each index corre- 
sponding to a component of a data set^s 
fully qualified name. The highest level 
index (the master index) is a set of user- 
identification codes, one for each user who 
has been granted access to the system . 
This master index is updated by the JOIl 
and QUIT commands given by the system 
administrators and manager. Each user ID 
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user's data set name structure must be 



Figure 2. System Catalog Concept 
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in the Master iii.iex points to a collecrtion 
of in.dexesy called the user catalog • lacli 
index in the user catalog corresponds to a 
leTel of qualification in the data set naae 
structure adopted by the user. Users , 
therefore, determine the nature of their 
catalog by the way they name their data 
sets. 



When a data set is cataloged,, the re- 
quired indexes are established in the user 
catalog in accordance with the fully quali- 
fied na«e of the data set. The lowest lev- 
el index in the user catalog is called the 
data set descriptor and, for data sets on 
dire<rt access volumes r it points to a data 
set control block (BSCB) that locates the 
individual pages of the data set. On mag- 
netic tape volumes^ the lowest level index 
of the user catalog gives the order , or 
sequence number^ of that data set on a par- 
ticular volume y relative to the beginning 
of the volume. 



The explicit cataloging of data sets 
through the comBiand systea will be dis~ 
cussed in Part III. Data sets created by 
the usual TSS accessing facilities (the 
virtual access methods) are cataloged auto- 
aatically when they are created. 



CHIT lECOHD DEVICES 



I key concept in efficient device man- 
ageaent depends upon the proper use of 

unit-record equipment (printers,, card 

readers, and punches) . By nature, this e- 
quipnent can not be concurrently shared 
among several users; a unit-record device 
must be allocated to one Job until it has 
completed using the device. Therefore nor- 
mal users are not allowed complete control 
over unit-record devices in TSS because one 
user might tie up, for an excessive time, a 
piece of equipment that is needed by other 
users . 



Host users obtain the services of unit 
record devices through the command system. 
Example: If a user wants to have a data 

set printed out, he issues a PlIHT command; 
the system then initiates a batch job for 
the printing and thereby makes most effi- 
cient use of the printer. 

Only users with privilege-class E (sys- 
tem monitors) can directly address specific 
unit record devices. In Part II, some of 
the access methods for this purpose will be 
described . 



CLASSES 0? SY0BA6B 



There are three storage crategories: 
■aim, auxiliarj, and external. Data is 
■oved between sain and auxiliary storage in 
a manner that is not evident to the user; 
these types of storage will be referred to 
only indirectly. External storageir howev- 



er. 



is of More direct concern to the user. 



FOBLIC AMD PRI¥AT£ STORAGE 

The two types of external storage avail-- 
able to users 2u:e public and private. 

Public external storage is that pool of 
storage available to be portioned out to 
users as they need it for creating or 
adding to their data sets. So that it will 
be a joint pool, capable of being appor- 
tioned efficiently, it Dust consist only of 
direct access storage. Direct access 
devices provide random access, so that pre- 
vious positioning is irrelevant, foluiies 
that are not direct access — for example, 
tapes — cannot have control over them 
interspersed randomly among tasks, since 
one task would have no indication of where 
the previous one had positioned the volume. 
Therefore, only with direct access volumes 
can different portions of the same volume 
be efficiently parceled out to different 
tasks for immediate access. Hence, only 
direct access devices c:an be used for pub- 
lic storage; the system specifies the 
devices, and the volumes remain mounted 
throughout a session . 

Private external storage is not a 
storage pool; it consists of volumes that 
may be allocated to only one task at a 
time. Because tape volumes can be allo- 
cated to only one task at a time, all tape 
volumes must be private storage. Also, di- 
rect access devices available to the sys- 
tem, which are not defined as public 
storage, are private devices that can be 
allocated to only one task at a time. 
Thus, private external storage may be ei- 
ther direct or seguential access volumes. 

The system assumes that a user wants 
public storage unless he requests storage 
on a private volume. Public volumes are 
always mounted and available for allocation 
to a user's task. 

If a user wants private volumes, he may 
need to wait for devices on which to mount 
those volumes. Each time a request is made 
for a private -volume device, the system 
must determine if it can honor the request, 
based on the current availability of the 



device type specified, and the device 
ration permitted for the user. If no 
device is available to the task, a message 
is issued to the user (in conversational 
mode) or the system places the task in 
abeyance until the needed device can be 
allocated (in nonconversational mode) . 
Conversational users can wait until a 
device is available, or perform other work. 



PBRMAHBHT AID TEHfOBARY STORAGE 

How can a public storage pool, available 
to all users, be rationed? One solution 
might be to give users as much as they 
want, whenever they need it. Unfortunate- 
ly, this flexibility might lead to a single 
user severely reducing the public storage 
available to other users (see Figure 3) . 
On the other hand, each user might have a 
maximum ration of 10% of the public 
storage. Besides being arbitrarily rigid 
(if only one person is using the system, 
why should he be so limited?) , this solu- 
tion limits the system to a maximum of 10 
concurrent users (see Figure 3) . 
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Figure 3. Public Storage lationing 
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Public storage is rationed under TSS bf 
restricting the extent that is allotted to 

any one user, but restricting it in a Mann- 
er that allows considerable flexibilitf 
during the time span of a gi^en task* Each 
user is allotted a aaxiaiia ration of peraa- 
nent r and a aaximna ration of teaporary 
public storage* Data sets specified as 
peraanent will continue to be on public 
storage after the task has logged-off ; data 
sets specified as temporary will be erased 
automatically by the end of the task. On- 
der this procedure, it is possible to 
allocate to a given user more than a strict 
percentage share of public storage,, since 
it is known that the portion of storage 
that is occupied by data sets specified as 
••teaporary" will be in use for only a short 
tiae. On the other hand^ since even the 
extent of teaporary storage available to a 
single user is limited by a fixed aaxiaua^ 
no one user can occupy an extensive area of 
public storage, even for a short tiae. 
Thus peraanent- and teaporary -storage 
rationing represents a coaproaise between 
the two situations depicted in Figure 3. 



aethods, the data set aanageaent {for exaa- 
pie, foraatting) is perforaed in virtual 
storage -- using virtual addresses that are 
part of the user's virtual storage address 
space — although physical device aanage- 
aent (e.g., I/O) is perforaed by systea 
programs in resident storage. Each access 
aethod provides access and processing capa- 
bilities for data sets organized in a spe- 
cific manner. 

• sequentially {firtual Sequential Iccess 
Method — VSIll 

• indexed sequential (firtual Indexed 
Sequential Iccess Method ~ fISlH) 

» partitioned (firtual Partitioned iccess 
Method ~ fPlH) 

In TSS, data sets organized for processing 
by one of the virtual access methods are 
generally referred to as flH data sets. 
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Three special Data Management Access 
Methods ~ the firtual Access Methods ffAH) 
— have been provided with TSS. They are 
specifically designed for a time-sharing 
environment and are used to read and write 
data to and from direct access storage 
devices- For all three of the ¥AH access 



VAM data sets reside on direct access 
external storage volumes, which are 
organized for aaxiaua accessing efficiency, 
lol'iiaes that contain VAM data sets can con- 
■^""'-^ ■"• '■■* only fAH data sets; the foraatting of 
tht;?>-"e volumes is described in Appendix A. 

The content of public storage consists 
exclusively of fAi data sets; direct access 
private storage, however, can contain ei- 
ther f AM data sets or data sets organized 
for interchange with any IBM Operating Sys- 
tea (of these latter, only physical sequen- 
tial data sets aim be accessed under TSS — 
see Appendix I for format descriptions) . 
f AM data sets are not on tape volumes 
(although they may be teaporarily stored as 
physical sequential data sets with the ¥T 
command, to be rebuilt in their original 
foraat by the Tf coaiaad*) 

Detailed descriptions of the various f AM 
data set organizations ara givc^n in Part 
II. 

lote ; Portions of fAM data sets do not 
reside in a user^s virtual storage until 
they have been read in by one of the virtu- 
al access aethods- firtual storage 
includes the portions of any data sets that 
can be directly referenced (having been 
previously read) , and may include data 
residing on aaim, auxiliary, or external 
storage (when the virtual access methods 
are used for reading) . 



DATI SET CHIE&CTERISTICS 



te hsLwm seen tkat a data set is an 
orfanized, logically related collection of 
records* fe will now briefly consider 
tbree basic ways that data sets are 
organized. 

A distinction should first be Bade be- 
tween two different types of records: log- 
ical and physicral. A physical record is 
considered from the standpoint of the mann- 
er or forn in which, it is stored^ retri- 
eved, and Boired — that is^ a record that 
is defined in terns of physical qualities. 
A logical record is considered independent- 
ly of its physical enTironnent — nore than 
one logical record nay be within a single 
physical record* 

Logical records are of prinary concern 
to the nser, since they are normally the 
nnits transferred to and from his problem 
program. Therefore, we shall refer to 
these simply as "records." 

The concepts of logical and physical 
records lead naturally to record blocking ; 
this is the combining of logical records 
into physical records that are to be trans- 
ferred to or from an external device. 
Blocking will be described in Part II. 

lecords may be in one of three formats: 
fixed-length (format -F) , variable -length 
(format-? or -D) , or undefined (f ormat-0) . 
Formats are discussed fully in Appendix C. 

lecrords are formatted, and the collec- 
tions of records (that is, data sets) are 
also formatted. The format characteristics 
depend upon how they are to be accessed; 
generally they can be grouped into three 
categories: sequential, indexed, and 
partitioned • 

Seguential Organizatio n 

When a data set is organized sequential- 
ly, the records are organized solely on the 
basis of successive physical positions, 
such as those of the records themselves, or 
of an associated pointer. One record pre- 
cedes another logically if and only if it, 
or its associated pointer, precedes the 



other record physically. This implies how 
the data set is to be accessed (that is, 
how the records are to be read in and out) • 
There is more discussion of this implica- 
tion in Part II. 



Indexed Organization 

A data set with indexed organization has 
a unique key associated with each of its 
records. The key is a string that usually 
represents an item within the record, such 
as a part number, date, or name. The key 
may form the basis for accessing the rec- 
ords, or several keys may be ordered to 
permit sequential accessing. Accessing 
this form of data set is also discussed in 
Part II. 

Partitioned Organization 

A data set with partitioned organization 
has elements, or members, that are other 
data sets; these elements are in either 
sequential or indexed organization. A 
characteristic of a partitioned data set is 
a control directory that provides informa- 
tion about the location and number of the 
elements of the data set, and the charac- 
teristics of each element. 

The organization within any of the three 
data set categories is dependent upon how 
the data set was created. Details of this 
dependence and data set organizations are 
in Part II. 

Application s The names of the data set or- 
ganizations were derived from combinations 
of the three categories and indicate chara- 
cteristics to the user. Example: VIS is 
virtual index sequential organization; the 
? signals a virtual storage data set that 
must reside on a direct access volume, pub- 
lic or private. The next two letters, IS, 
provide progressively deeper levels of 
detail; "index" reflects that the logical 
order of the records of the data set is de- 
termined by a key; "sequential" indicates 
that the keys are arranged in an ascending 
collating sequence that provides an option 
of strict sequential access. 
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HAWIPPIiATIMG AMD SHARIgG DIfl SETS 



The characteristics of am individual 
data set Bust be clearly defined to the 
sfstea before the user can create or access 
that data set bf using the system's data 
Banagenent facilities. 

Does the user want to write to the data 
set, read from it, or both? The system 
must have indications of how he intends to 
access a data set so that the routines that 
he will need will be available. 

Boes he want to provide his own routines 
for handling some processing interruptions? 
If he does, the system must have the ad- 
dresses of these routines before it can 
start processing. 

Such indicators are required at differ-- 
ent times, and the sources of the indica- 
tions differ: the user provides some and 
the system others,. Control blocks act as 
storehouses for this information; the sys- 
tem will reference this information when it 
is required. 



3CB AMD JFCB 

lost of the physical characteristics of 
a new data set are stored in the data c:on- 
trol block (DCB) , which normally resides in 
a user's program and is generated at 
assembly time. In addition to such static 
qualities as data set organization, the DCB 
contains information about processing re- 
quirements, among them the number of buf- 
fers required for input/output operations. 



I particular DCB is not directly linked 
to any data set; rather, it is a "floating*^ 
definition that can be linked to a specific 
data set through an intermediate job file 
control block (JFCB) , as shown in Figure 4. 

The JFCB gives the user the flexibility 
to associate a DCB with a particular data 
set at the command-system level, anytime 
before executing a particular program. The 
user establishes the JFCB by issuing the 
DDEF command or macro instruction (or the 
CDD command, which copies prestored DDEF 
cx>mffiands) • 



lyTRQDDCIWG A DATA SET TO A TASK 

Besides creating a JFCB to link a data 
set and a DCB, the DDEF command (or macro 

instruction) introduces a data set (speci- 
fied by its data set name) to a user's 
task. For a new private data set, the nec- 
essary messages are issued to the operator 
to request mounting of any required private 
volumes. If any volumes cannot be mounted, 
conversational users are informed by system 
messages; nonconversational tasks are ei- 
ther terminated by the operator or queued 
until the required private volunes have 
been mounted. (For nonconversational 
tasks, a list of private device require- 
ments is made available to the system by 
the SECURE command ^ which the user must in- 
clude in the task's nonconversational SIS III 
as the first command after LOGOM.) Then, 
as each DDEF is read and processed, the re- 
quired devices are allocated. 
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Figure ^. Data Sat Description Control Blocks for Cataloged/Pncataloged Data Sets 



for an existing data set witk DISP=0LD 
ezplieitlf stated y if a private (PS) data 
set is indicated tte systes reguests nount* 
iiif of appropriate Tolnaes. If a public 
(fl, tS, or fP) data set is indicated, the 
sf stem searches the catalog for the data 
tet naii# and, if it does not find the naae 
(that* is, the data set is not cataloged) , 
the sfsten cancels the DDEF. 



7he catalog and DDIF values for data set 
organitation, data set disposition, and 
device tfpe enst agree or the connand (or 
nacro instrnction) is canceled. In all 
other cases of conflict, catalog informa- 
tion is used to fill out the JFCB, in pre- 
ference to the conflicting information in 
the Ol>tf command or macro instruction. 
Since the user will not be informed of such 
conflicts, he should be avare of the JFCB 
fin hierarchf used. 

for a new virtual storage data set 
(MSf^lll) , the DBEF command or macro in- 
struction is canceled if the specified data 
set name already exists in the catalog. 

Within any particular task, there can be 
only one JFCB for a data set. If a user 
issues a new DD2F with a data set name that 
is identicial to that in a previous DDBF, a 
mew JfCB will not be created. Instead, the 
ddname in the new BBBF will be substituted 
for the ddname currently in the JFCB, and 
processing for that DDBF will be considered 
complete, fhis will have the effect of 
associating a new DCB (the one associated 
with the ddname now in the JFCB) with the 
nai^d data set. 

the user can specify, in the DDIF, pa- 
rameters for external storage space- 
allocation, device management, data set 
disposition, and DCB, that are to be put in 
the JfCB. The user may want to alter some 
parameters before executing a program, but 
issuing another DDEF with the same data set 
name will not affect any parameters in the 
JFCB, other than the ddname. If he issues 
the IILIISI command, the user can change 
parameters placed in the JFCB by a previous 
DDtF. 

k DDIF command or macro instruction is- 
sued during a task is valid throughout the 
task, unless the user issues a BILEISI com- 
mand for the data set named DDIARI in the 
DDtf • the IILEASE command releases the 
JFCB associated with a data set, removing 
the control information in the JFCB and 
disassoirlating the data set from a DCB. 
Releasing a data set does not uncatalog or 
erase it. If a private data set is re- 
leased, and the volume on which it resides 
contains no other in -use data sets (i.e., 
data sets for which there are current 
JFCBs) , then the 1/0 device on which that 



volume resides will be automatically freed 
for other uses. 



Summary of DDEF Operands 

Headers who require an in-depth treat- 
ment of the parameters available should 
consult Command System User's Guide or 
Issembler User Hacro Instructions. 



DDIAME : fhe symbolic data definition name 
that serves as the link between the DCB 
and the JFCB; since the JFCB, in turn, 
points to the data set, the DDNAMl con- 
nects the data set attributes to a spe- 
cific data set. 

DSQHG ; Indicates the organization of the 
data set being defined; specification of 
this parameter must be correlated with 
the a.ccBss method to be used in process- 
ing the data set. 

DSWAMB ; Specifies the name under which the 
data set is to be cataloged or referred 
to for temporary reference; for data sets 
that are cataloged, this serves as the 
link between the JFCB and the data set. 

DCB ; Under this heading, parameters may be 
stored in the JFCB; these will be re- 
ferred to when a data set is opened, for 
the purpose of filling out the DCB (see 
■•Preparing Data Sets for Use") . 

OMIT ; Specifies the type of device re- 
quired by the data set. Direct access 
devices may be specified for either pub- 
lic or private volumes; other types of 
devices may be specified for private 
volumes only. 

SPACE : Specifies the storage allocation 
for a data set that is to reside on di- 
rect access storage. Both primary and 
secondary space allocations can be speci- 
fied; secondary space is to be allocated 
when the primary space has been filled. 

LABEL : Applicable to data sets that are on 
tape, this operand specifies the sequence 
number (relative position) of a data set 
on a tape that contains multiple data 
sets. Also, this operand may specify the 
labeling conventions used with a data 
set; that is, if a data set is labeled 
and if the label is standard EBCDIC, 
standard ACS II, or user-created . 

RETPD : Specifies the number of days the 
data set is to be retained by the system 
(retention period) ; applicable only to 
non-VAH data sets on direct access 
volumes or labeled tapes. When the spec- 
ified time has elapsed, the volumes are 
available for reuse. 
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The assembler user initiates processing 
by issuing the OPEM macro instruction; for 
users of higher-level languages it will be 
automatically issued. When the data set is 
opened, the DCB is completed by filling in 
information obtained from: 

1. Users' modification routines (BSIH 
only) 

2. The DCB itself 

3. The JFCB 



MSP: Specifies whether the data set 
already exists or is to be created. If 
DISP is not specified, the system deter- 
mines if the data set is new or old, 
based on whether there is a catalog entry 
for it; if yes, it is assumed to be old; 
if no, it is assumed to be new. If there 
is conflict between the specification of 
this operand and the state of a data set, 
the DDEF command is canceled. 

QPTIOH : Specifies that either a job li- 
brary is being defined or a data set is 
being added to the concatenated data set 
named in the DDIUIE operand. I data set 
that is to be concatenated must exist in 
physical sequential organization. I job 
library that is being defined must be 
virtual partitioned; it will automatical- 
ly be placed at the top of a list of job 
libraries defined during that task, and 
will be used to store object modules un- 
til either it is released, or a new job 
library is defined on top of it (job 
libraries are searched for object modules 
in the reverse of the order in which they 
were €nreated) . 

RET : Specifies the storage attributes of a 
¥11 data set. The user may specify per- 
manent or temporary storage, that the 
data set is to be erased after the CLOSE 
or lOSOFF, or that either unlimited or 
read-only access to the data set is 
permitted . 

PROTECT: Applicable to data sets on tape, 
this operand specifies whether file pro- 
tecrtion, that is, no file protect ring, 
is required. 



PREPARIHG A DATA SET FOR gSE 

Even after a data set has been defined 
to a task and link^ to a DCB by the crea- 
tion of a JFCB, it is still not ready to be 

pro<»ssed; the DCB may not be completely 

filled in, and the data set is not initial- 
ly positioned. "Open processing" must be 
completed before the access methods can 

process the data. set. 



4 . The system catalog (for existing data 
sets) 

5. Existing data set labels 

lot all of these sources are valid for 
each field of the DCB. Two general rules 
Q^PPiy* when a field is filled in by a 
higher priority source, it cannot be 
replaced by information from a lower 
priority source; if a field has not been 
specified by a higher priority source, it 
may be filled in by a lower priority source 
if that source is valid for that field. 
This flow of information is illustrated in 
Figure 5. 

Open processing logically consists of 
two functions: a common portion that per- 
forms the services required by all access 
methods, and an access-method-dependent 
portion that completes the processing re- 
quired by the pertinent access method. 

The common portion first ensures that 
the DCB is valid; if not, the user's task 
will be abnormally terminated. Since the 
DDMAIE parameter is required to provide the 
needed link between the DCB and the JFCB, 
before any filling in can begin a check is 
made to ensure that this parameter is in 
the DCB and that it corresponds with an 
identical parameter in some JFCB for that 
task. In case of any discrepancy, conver- 
sational tasks will be prompted and noncon- 
versational tasks will be abnormally termi- 
nated. The user's authority code is 
checked to ensure that he is privileged to 
open this data set; if he is not, the task 
is abnormally terminated. 

The access-method-dependent portion of 
OPEW completes any processing required for 
the device on which the data set is 
mounted, processes tape labels according to 
the open option specified (IIPUT, OUTPUT, 
I1O0T, OUTIl, HDBACK, or UPDAT) , initially 
positions the data set, and sets up the 
linkages to the routines that may be used 
in accessing this data set. The routines 
that may be used depend upon the combina- 
tion of the access method being used, the 
option with which the data set was opened, 
and the macro instruction references speci- 



10 



fied in the DCB. fhe initial positioning 
for non-fAH data sets is dependent upon the 
option with which the data set was opened, 
together with the DISP option of the DCB 
(OLD, HEW, or EOD) . 

Open processing for new fAM data sets 
includes creating catalog entries for these 
data sets; this occurs during coiiaon open. 

Jnst as OPIM completes the logical con- 
nection between a data set and a DCB, per- 
mitting the data set to be accessed by the 



problem program, so CLOSE eliminates this 
link, removing the data set from direct 
contact with the problem program, and per- 
mitting it to be connected to a different 
DCB (or the same DCB, with different param- 
eters) . Then the data set can be accessed 
as a data set with different physical 
characteristics. (Mote that this applies 
to the normal use of CLOSE; a more re- 
stricted form of the instrncrtion, CLOSE 
(T) , will be discussed below) . 
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Pignre 5. Flow of Information To and From a Data Control Block 
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Processing of CLOSE also consists of a 
comaoii and an access-«ethod-€ependent por- 
tion. Tlie coaaon portion disconnects tlie 
DCB fro» the data set by returning the 

fields that were filled in during open 
processing to the condition thef were in 
before the DCB was opened ^ Ifter perform- 
ing other processing , control is passed to 

the access~method-de pendent portion, which 
checks all outstanding I/O operations for 

completion and then repositions the data 

set ¥oltt«er if necessary {physical seguen- 

tial data sets) . Ippropriate label proc- 
essing is also performed; the type of proc- 
essing is depend^it upon the option with 
which the data set was opened* Example: a 
physical sequential data set that was 
opened for OOTPOf will have appropriate 
trailers written when it is closed. 

I temporary close, CLOSE (T) ^ can be per- 
formed if the user wants to reposition and 
consolidate r tat us information, without 
disconnect iEa the data set from the problem 
program r by reiioving the link between the 
data set aad the DCB . He may subsequently 
perform additional processing on that data 
set without again opening it. (For VP data 
sets^ the FliB macro instruction must be 
issued prior to any further processing.) 
The temporary close performs the same proc- 
essing as the standard CLOSE aacro imstruc- 
tion, except that the fields of the BCB are 
not restored to the status they wej-e in be- 
fore opening. Also,- if the user has speci- 
fied the delete- at -close option in the DBEF 
for a data set, the standard CLOSE macro 
instruction will ermse the data set before 
returning control to the user; CLOSE (T) 
win not. 



The Duplexing Option 

For public ¥IM data sets, an option pro- 
vides for parallel creation and updating of 



two identical copies of a data set. With 
this option, when a user changes one copy 
of the data set, the system will automati- 
cally change the other copy . 



The DOPOPll macro instruction is used 
instead of OPEN when the user wants the 
system to maintain a copy of the data set. 
The user specifies, in the DUPOPEM macro 
instruction, the locations of the DCBs of 
the data sets to be maintained in parallel; 
in response, the system links the JFCBs as- 
sociated with these data sets and allocates 
any necessary storage. Since the purpose 
of duplexing a data set is to provide pro- 
tection against loss of virtual storage 
data sets through volume errors , external 
storage for each copy of the data set is 
allocated, wherever possible, on mutually 
exclusive physical volumes. 



If an input error is detected on a page 
of the primary data set, the corresponding 
page of the secondary is obtained and used 
for input, and, also, is written back to 
overlay the logical page with the error on 
the primary data set. This process not 
only recovers from the error, but also 
tends to keep the primary copy in an error- 
free state. 



To close duplex data sets, the DOPCLOSE 
macro instruction is used. To ensure that 
the two copies of the data sets are identi- 
cal, the user must perform all operations 
on either data set within the duplexing 
mechanism {i.e., opened with DUPOFBN, and 
closed with DOPCLOSE) . Errors will be in- 
dicated if the BCBs associated with dup- 
lexed data sets indicate conflicting attri- 
butes; similarly, the sharing properties 
specified in PERMIT commands (discussed in 
"Sharing Data Sets") must agree. 
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SHABING DATA SETS 



la Baiif appli cations, aore than one user 
may need the sa«e iata. Two or nore users 
»ay irant information from the same source 
of data or they may want to update the same 
^opy of data- Enabling users to share one 
copy saves storage space; it also eli- 
minates the need to collate information 
from different copies of the data to form a 
single updated copy. 
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The user who authorizes sharing of a 
portion of his catalog is the "owner"; 
anyone authorized by the owner to share is 
a "sharer". The owner can specify the 
class of accessing privilege of the sharers 
of a data set or index level: 

Onlimited access — Sharers may read 
from the data set or modify it in any 
way; they may eirase it. 

gead—write access — Sharers may read 
from the data set or modify it; they 
cannot erase it. 

Read~onlv access — Sharers may only 
read from the data set; they cannot 
modify or erase it. 

Note: Xn the JFCB, there is a flag indica- 
tion of whether a data set is sharable; 
issuing a PEEMIT command does not alter an 
existing JFCB. Therefore, if a user 
decides to share a data set after he has 
already issued a BDBP for it, he should re- 



lease the existing JFCB (by the BELEASE 
command or by logging off) and issue anoth- 
er DDEF for that data set, so that it will 
be flagged as sharable. 

Through the PERMIT command, the owner 
can specify a data set or index level as 
universally sharable or he can explicitly 
specify the users who may share it; this 
information is placed in his catalog. 
Through the SHABE command, the sharer pro- 
vides the linkage between his catalog and 
owner's catalog, and specifies this 
information: 

Owner's ID, 

Fully qualified name assigned by the 
owner to the data set or index level. 

Fully qualified name assigned by the 

sharer. 

Example: The owner, Oser 1, whose ID is 
0SEB1, specifies other users who may share 
index level A.B. Oser 2 wants to access 
Oser I's data set A.B and call it X.I. 
Oser 2 must then specify USEB1.A.B and X.Y 
as parameters for the SHABE command. When 
User 2 wants to access data set X.I a cata- 
log search will be made through index 
levels X.I.0SEB1.A.B to reach an entry in 
Oser 1»s catalog (see Figure 6). 

Sharing Private Storage 

All data sets in a user's catalog, on 
either public or private storage, can be 
shared externally. However, since private 
volumes must be mounted on private devices, 
and private devices can be allocated to 
only one task at a time, a sharer may find 
that a private data set is unavailable to 
his task for one of two reasons: 

1. There is not an appropriate private 
device available for allocation to his 
task. 

2. Another sharer is currently using the 
data. (The private volume will not be 
available until he releases the JFCB 
or logs off.) 

Sharing Public Storage 

If the shared data is on public storage, 
the data set can be open and accessible to 
more than one task . When data is shared 
concurrently, records may be read and writ- 
ten by different users without any one hav- 
ing to close the DCB he has open for that 
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Figure 6. Example of ExterEal Skariag 



data set. The shairer maj have to wait un- 
til an interlock, set by another sharer's 
task, has been released, but this is the 
only restriction on the availability of the 
data. Two interlocks, read and write, con- 
trol concurrently shared data. 



A read interlock is imposed to prevent 
other users from writing into a data set, 
■eaber, or page of a data set. Multiple 
read interlocks may be established for a 
data set or member ^ permitting several 
users to read it simultaneously, or the 
interlocks may be set on a page basis to 
give several users simultaneous access to 
the records within a page. A read inter- 
lock cannot be set if a write interlock has 
already been set for the data set or page. 
(For a VISIH data set, a data set level 
read interlock is slightly less restric- 
tive; it prevents other users from opening 
that data set for output.) 



A write interlock prevents any user, 
other than the user who set the interlock, 
from reading or writing into a data set, 
page, or member. Only one write interlock 
can be set at a time; thus, once a write 
interlock is set, neither read nor write 
interlocks can be applied until the write 
interlock is reset. 



Data Set Interlocks ; I data set interlock 
is set according to the option with which a 
data set was opened (INPUT, OUTPUT, IMOUT, 
OUTIH, or UPDIT) . It has the effect of 
restricting the OPEH options that will be 
accepted from future concurrent users; such 
users will be prevented from opening a data 
set with an option against which it is 
interlocked. 

Member Interlocks ; Partitioned data sets 
are interlocked at the member level, rather 
than the data set level; these interlocks 
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are set within the Meiiber header associated 
with the data set. 

Page Interlocks ; In shared fISIM data 
sets^ interlocks are set at the page level; 
these interlocks are set by VISIH macro 
instructions . 

Data set and seaber interlocks arc* re- 
leased when the data set is closed ^ or the 
aeaber is stowed; page interlocks are re- 
leased when a reference is made to another 
page in the data set ^ when an ISETL or 
BELBX macro instruction is issued ,r or when 
the data set is closed. 



IITERBAL SH&RIHG 

When virtual storage is shared internal- 
ly , only one physical copy of the data is 
required in main storage, and is a part of 
the virtual storage of all the sharers. 

One example of internal sharing is the 
shared data set table (SDST) . It exists as 
part of the virtual storage that is ini- 
tially allocated to all tasks when they 
execute LOGOS, and is updated with entries 
for internally shared portions of shared 
data sets when the data sets are initially 
opened; users who subsequently open this 
data set reference this table, and incre- 
ment the count of concurrent users in the 
table. 

Internal sharing is effected by the 
dynamic loader for control sections with 
the PUBLIC attribute; the SDST serves as 
the link to this shared virtual storage. 



The difference between internal and ex- 
ternal sharing is illustrated by the sys- 
tem's treatment of PUBLIC and PBIVITl con- 
trol sections in shared data sets: 



User I wants to share module I with 
user B. Module A consists of two control 
sections, one with the PlIVITE attribute, 
the other with the PUBLIC attribute. 

Since an object module exists as a 
member of a partitioned data set (let us 
call it JOBLIBIL) and only entire data 
sets are shareable. User I must share 
data set JOBLIBI with User B. So User I 
issues a PEIMIT command, naming JOBLIBA 
to be shared and User B as sharer. User 
B later issues a SHARE command, naming 
JOBLIBA. He decides to refer to this 
data set, for brevity, as LIB A and speci- 
fies this in his SHARE command. 

User B now issues a DDEP for LIBA, 
specif ing that it is to be a job library. 
Sext, he requests the loading of module A 
from LIBA by calling that module. 

But User A has already loaded module A 
and is presently executing it. The sys- 
tem will "connect" the PUBLIC control 
section already in shared virtual storage 
(it was loaded by User A> to User B»s 
virtual storage; also, it will obtain a 
new copy of the PRIVATE control section 
from external storage and load it into 
User B»s virtual storage. Thus User B is 
sharing module A with User A, although 
only one of the module's two control sec- 
tions is being shared internally. 
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The sfstem's access methods are at the 
heart of the data aanagement routines. 
These are the techniques by which data is 
transferred between virtual and external 
storage. Since users amst bring data into 
virtual storage to exauine or process it 
internally, these access methods are con- 
stantly employed. Indirectly, they are 
used by FOITEIM, the coaaand systea, or a 
related method. General explanations of 
these interfaces are in Part III. Issea-- 
bier users have a more direct link to these 
access methods through the macro instruc- 
tions that they employ « The access methods 
are described, in terns of these macro in- 
strucrtions, in the sections that follow. 

The access methods available to users 
fall into one of two catagories: the vir- 
tual access methods (flH) , and the sequen- 
tial access methods (SIl} . 

The virtual access methods take maximum 
advantage of the time-shared environment of 

TSS and free the user from device consider- 
ations. When a ¥KE user creates a new VIM 
data set on public storage, the system 
allocates the needed storage from the pool 
of public volumes, and automatically cata- 
logs it for the user . The data set may be 
spread across different public volumes, or 
even different device types, but it will be 
controlled as a logical entity for the 
user. ¥11 also uses the system^s paging 
facilities for data transfer between exter- 
nal and main storage. So, the system can 
ensure efficient allocation of main storage 
by reading in only the pages of a data set 
that are being referenced during a particu- 
lar time slice. This paging is not evident 
to the user and should not be confused with 
"reading into virtual storage* when a VII 
user accesses a data record. 



When a page conta 
into virtual storage 
ters are set up to " 
the user's virtual s 
location will then b 
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The sequential access methods provide a 
range of functions not available under VAi. 
Example: SIl users may access magnetic 
tape directly, or may access certain data 
sets created under the Operating System. 
However, the sequential access method KSIH 
is restricted to privilege -class E users 
and system routines; all it requires is 
that a user be authorized to access private 
volumes. Since SIH always requires the 
allocation of a particular private device 
to an individual user»s task, SIH users 
will be forced to wait until the system can 
fulfill this need for a private device; 
this restriction does not apply to VII 
users unless they are using private VIM. 
Finally, SIl can not take advantage of the 
system's paging facilities for record input 
from external storage; the SIl user must 
directly control the length of the physical 
record to be read into main storage. The 
SIl user's instruction, lEID or GET, has a 
more immediate relation to actual data 
transfer than under VIM (that is, the input 
buffer will be filled as a result of the 
SIH macro instruction, not because of any 
subsequent reference to that record) . 

Users who access existing data sets are 
constrained (in terms of the access methods 
available to them) by the physical struc- 
ture of the data sets. Example: Osers who 
employ VII must be sure that the data sets 
they are accessing are of VIl organization. 
Osers who create new data sets must base 
their choice of access method upon the uses 
to which the data set will be put, as well 
as the system environment of TSS. Example: 
Users who want to store their data sets on 
tapes (perhaps to take advantage of the 
limited data set interchange with the Oper- 
ating System) will employ the sequential 
access methods; users who want to take max- 
imum advantage of the time -shared environ- 
ment of TSS will employ VII. 

Within VIM or SIl, which dtccess method a 
user should choose is determined by the 
manner in which he wants to access a data 
set. Example: When a data set, or a sub- 
stantial portion of it, is to be processed 
sequentially, the GET and PUT macro in- 
structions will often be the most efficient 
and convenient to use. 

In determining the access method for 
creating a new data set, the user will in 
many cases be implicitly determining a 
great deal about the structure of that data 
set. Example: I user who selects VISIM to 
build a data set will automatically 
organize it as a VII data set (see Ippendix 
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1) and will restrict himself to the per- 
missible record formats (F or V) . Within 
the determined framework, the user can 
choose the record format that best fits the 
employment of the data set. k typical con- 
sideration might be processing speed.. 
Sincre the access method must determine the 
recsord length for each individual record 
from the record itself r fo^ format-? rec- 
ords, processing is slower than for format- 
f records r in which all lengths are the 
same. Therefore, when a data set will con- 
tain records of uniform lengths, or records 
that can, without much loss of space, be 
padded to uniform length, format-F is the 
most efficient. 



▼Iff OIL ACCESS HETHO DS — ¥AH 

the virtual access methods (¥IM) are the 
principal means of data access in TSS. 
There are three virtual access methods, 
each of which provides access and process- 
ing irapability for a specific type of data 
set organization: 



Virtual sequential access method (¥SAH) 

firtual index sequential access method 
(VISAl) 

Virtual partitioned access method (VPAM) 
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connects the data pages, through the rela- 
tive external storage correspondence table 
(BESTBL) , which is in virtual storage. 
When data sets are opened, the system allo- 
cates virtual storage for the RISTBL; when 
they are closed, the virtual storage previ- 
ously occupied by the RESTBL, is released 
and becomes available for system use (for 
shared data sets, the virtual storage for 
the RESTBL is only released when the last 
BCB for that data set is closed) . On ex- 
ternal storage, the information relating 
(a) the relative page numbers within the 
data set to (b) relative page numbers on 
the system "s external storage is kept in 
data set control blocks (DSCBs) . The DSCBs 
are used as source input to create the 
BESTBL and they are updated, when the data 
set is closed, to reflect changes to the 
data set. 



A data set may be fragmented, for exam- 
ple, when its size is being increased dur- 
ing different tasks. When a virtual 
storage data set is being created, a prede- 
termined extent of external storage is 
allocated to it (this extent nay be deter- 
mined by user specification or system 
default J . When the data set is clos<»d, 
pages assigned to the data set that were 
not used will be freed (returned to the 
pool of available public storage) . If, 
later, he increases the size of his data 
set, the additional external storage allo- 
cated may not be physically contiguous to 
the initial storage. The user is unaware 
that his external storage is not physically 
contiguous, since VAM organizes data sets 
by relative page number and logically 



The page-sized data blocks, into which 
virtual storage volumes are divided ,r are 
used by ?AK as the unit of transfer between 
the direct access device and main storage. 

The page-sized block for data storage 
was selected for a number of reasons. It 
is large enough so that direct access 
throughput is high, and the frequency of 
access requests by each user will be low. 
The direct access volume-packing efficiency 
is also quite high for page size blocks. 

Processing Data Sets with VAB 

Before a user can process a data set, he 
must DDEF it (directly or indirectly) , and 

open the DCB associated with the data set 
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The overall concept of the virtual 
access sethods, shown in Figure 8, includes 
the data transfers and logical relation- 
ships that occur when a user opens an ex- 
isting VIM data set, uses VIH to request a 
logical record from it, and references that 
re€3ord for the first time. 

When the user opens the data set ini- 
tially, the information in the existing 
DSCBs is used by the OPEM routine to con- 
struct the EBSTBL (1, in Figure 8). When 
he subsequently issues a locate-mode GET, 
the external storage address of the page 
containing the record is obtained froa the 
HESTBL, and placed in an external page ta~ 
ble (XPT) entry, which is associated with a 
virtual storage buffer (2, in Figure 8) . 
lote that the external page containing the 
record is not read into' Bain storage at 
this ti«e. When the record in the virtual 
storage buffer is referenced, a paging re- 
location exception interruption occurs, and 
the paging mechanism proceeds to bring the 
page into aain storage (3, in Figure 8). 
Thus VAH ensures that only the pages of a 
data set that are actually required for 
progran execution are brought into aain 
storage froa external storage. 

firtual Secruential Access Hethod ■ — VSIH 

The virtual sequential access method 
(¥SIII) processes virtual sequential data 
sets and virtual sequential members of par- 
titioned data sets. It can be used for any 
of these functions: 

Create or extend a virtual sequential 
data set or virtual sequential member of 
a partitioned data set. 

Belete all records in an existing data 
set or member from a specified record to 
the end of the data set or member 
(truncation) • 

Retrieve the logical records of the data 
set or member in a sequential or nonse- 
quential manner. 

Opdate, in place, an existing record of 
the data set or member. 



To use VSiM to process a data set, that 
data set must have virtual sequential (VS) 
organization. Is elements of a sequential 
data set, the records in a VS data set are 
ordered strictly by the sequence in which 
they were created. The user, in creating a 
VS data set, must provide the system with a 
stream of logical records that are concat- 
enated and stored, page by page, on direct 
access devices. As each record is stored, 
the system makes its retrieval address a- 
vailable to the user's program. Users emp- 
loying the assembler language can form 
another virtual sequential or virtual index 
sequential data set that contains these re- 
trieval addresses. If the user wants to 
make an orderly sweep through the data set 
after he has created it, he can read the 
records back, in the order of creation, by 
requesting one logical record after anoth- 
er. In assembler user can also read and 
update logical records nonsequentially by 
specifying the required retrieval addresses 
of the records involved in SETL macro in- 
structions; the retrieval addresses are in 
the data set that he formed. 



Ill buffering required for VSIl process- 
ing (except for format-U move-mode, where 
the user's buffer is on a page boundary) is 
supplied by the system, based on the maxi- 
mum logical-record length specified in the 
appropriate data control block. VSIM log- 
ical records may be format-F, -V, or -0. 
Record formats are described in Appendix C. 

The macro instructions associated with 
virtual sequential data set processing are 
SETL, GET, PUT, and FUTX. 

SET! specifies a logical record to be pro- 
cessed, using fSIH. The user needs to 
specify this macro only if he wants to 
process a record other than the next 
sequential one in a data set. SETL is 
called as a part of open processing, to 
initially position the data set for proc- 
essing. If the DCB was opened for input, 
update, or in-out, SETL positions the 
data set at its logical beginning; if 
opened for output or out-in, the data set 
is positioned at the logical end. 

GET obtains sequential access to a record 
of a VSIM data set. It may be specified 
by the assembler user in one of two 
forms: 

Hove Mode — The user provides the sys- 
tem with the address to which he wants 

the record transferred; the system 
moves it. 

Locate Rode — The user requests the 
virtual buffer address of the next log- 
ical record in the input buffer in 

which the next logical record is 
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stored. Ixtli tkis adiress^ the mser has 
the option of processing the record at that 
location or aoving it to his own work area, 
la ••locate Bode^" there is bo actual record 
transfer until the user references the rec- 
ord and a page relocation interruption 
occurs; this is ala3 true for foraat-l rec- 
ords in *move-Bode»*» 



In processing foraat-1 rea>rdsy the 
user must specify their lengths in the 
data control block prior to issuing the 
SBT macro instruction; WSAE format-l rec- 
ords Bttst be e¥en-aiiltiples of a page. 

ifter each execution of the GET aacro 
instruction ,Ci^ either node) p the re- 
trieval address of the logical record 
just retrieved is in a data control block 
field. The user ma.j create a secondary 
data set froa all his GET retrieval ad- 
dresses to facilitate future nonsegiien- 
tial processing of the original data set« 

Successive GBT aacro instructions will 
retrieve the records of a data set in the 
seguence of creation. When the system 
detects the end-of-data condition while 
processing a GET instruction, the systea 
will transfer control to the user's end- 
of-data fBODAD) routine. To start 
sequential processing at a point other 
than the beginning of a data set^ the 
user can specify the retrieval address in 
a SETl macro instruction, prior to issu- 
ing the GBT aacro instruction. 

Similarly , to directly access any rec- 
ord in the data ^t when its data control 
block is open, the user can specify its 
retrieval address in a SITL macro in- 
struction and then issue a GBT aacro in- 
strucrtion to obtain it* 



the record to the output data set when 
necessary . 



The user Must specify the length of 
the logical record for each PPT macro in- 
struction* For for»at-F records, this 
information is in the data control block 
and is the same for each record in the 
data set* For foraat-U records, the user 
stores this information in the data con- 
trol block prior to each PUT^ For 
format-? records, the lengths must be 
supplied within each logical record by 
the user. The length of each logical 
record must not exceed the Baxiffluii speci- 
fied in the data control block at open 
tine. 



When a PUT aacro instruction is issued 
in either mode , the retrieval address of 
the record to be stored is made available 
by the system (in a data control block 

field) . The user can store these ad- 
dresses, and use them in the SETL macro 
instruction for later nonsequential proc- 
essing of the data set. 



The POT macro instruction may also be 
used to truncate an existing data set. 
Since the system automatically generates 
an end-of-data indicator as part of the 
execution of every PUT, the user could 
issue a SET! instruction to position a 
volume at, say, the middle of a data set, 
and then issue a PUT for a certain logic- 
al record; the system will then indicate 
that the record is the new end of the 
data set. The records that were previ- 
ously in the last half of the data set 
have now been deleted. 



PUT places logical records into an output 
data set when a virtual sequential data 
set or member is being created or added 
to. In addition to concatenating records 
into a data set, PUT defines a new end- 
af--data set to the system each time it is 
issued* It may be issued by the assem- 
bler user in either of two forms: 



Hove Mode — The 

tem with the add 

ord; the system 
from that locati 
ble output buffe 
the system autom 
record to the ou 
that portion of 
or reused* 



user provides the sys- 
ress of a logical rec- 
transfers the record 
on to the next availa- 
r segments From there, 
atically writes the 
tput data set before 
the buffer is released 



Locate Hode ~-* The user requests, from 
the system, the address of the next a- 
vailable output buffer segment. He 
uses that addr^^s to store the logiiral 
record that he wants to add to the data 
set; the system automatically wx^ites 



PUTl rewrites an updated logical record 
from an input buffer area, back to a data 
set on external storage; the record must 
have been brought from external storage 
to the buffer area by the execution of a 
locate-mode GET instruction. If the user 
attempts to change the length of the rec- 
ord he is updating, or if the DCB associ- 
ated with that data set was not opened 
for update, the user^s task will be 
abnormally terminated. 



VSIH Sharing Controls : The system provides 
interlocks for shared virtual sequential 

data sets: If a fS data set is opened for 
input, other users can read the data set, 
but they cannot write into it; if a ¥S data 
set is opened for output, update, in-out, 
or out-in, no other user may have any 
access to that data set; the data set can- 
not be opened for these options if anyone 
else is using it. Ill interlocks are auto- 
matically removed when a data set is 
closed • 
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virtual Index Sequential Iccess Method 
VISAH 

The virtual index sequential access 
method (fISAM) processes virtual index 
sequential data sets and virtual index 
sequential members of partitioned data 

sets. It can be used for any of these 
functions: 



Create a virtual index sequential data 
set or meiiber, in a sequential or nonse- 
quential manner. 



Hetrieve the logical records of the data 
set or meaberr in a sequential or nonse- 
quential manner • 



Update records in a sequential or nonse- 
quential Banner. 

Insert new records in their logical 
sequence within the data set or senber. 

Delete selected records from the data 
set or member . 



number of data pages in the dataset exceed 
one. There is one Icef entrf in the direc- 
tory for each data page in the dataset ex- 
cept page 1 (PPM 0) . The kef entry con- 
tains the logical position of a page in the 
dataset as well as its physical location. 
Key entries are in the following format: 



Bytes 

0-1 

2-3 
4-5 

6-9 



logical page number (LPN) this key 
entry 

physical page number (PPM) this key; 
location of this page relative to 
1st data page of this dataset 

old physical page number (OPPH) on 
the page; PPM value on page before 
its physicall page number relative 
to the dataset was changed 

spare 

low key on this page^ rounded to a 
half word boundry 
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The 1st 2 bytes of each data page con- 
tain the PPM of the page. A page's PPM 
number will always equal the PPM value in 
the directory unless there have been some 
pages deleted^ in which case the old page 
PPM is saved in the key entry. This PPM 
number is used for validity checking of 
IISAI pages by the VISA! input page routine 
to ensure dataset integrity. Mew pages are 
always added to the end of the dataset even 
though they may logically represent an ins- 
ertion somewhere in the middle. By adding 
pages at the end and maintaining a transla- 
tion mechanism the need for overflow pages 
is eliminated. 



Insertions (records) are added to an ex- 
isting full data page according to the fol- 
lowing rules: 



A. If the new record to be added to the 
dataset is going to be the last record on 
the paget a new page is added to the end of 
the dataset, and the new record (key) will 
become the low key on the new page. The 
key entry for the new page will be inserted 
in the correct logical position in the 
directory. 



B. If the new record is not the last 
record on the page all records with a key 
value greater than the new record will be 
moved to a new page and a new key entry 
added to reflect the new page. The new 
record may or may not fit on the old page . 
If it does not proceed with (a) above. 
(See Figures 9A - 9C.) 
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Figure 9C* Additioii of record 8 KEY350 to 
Figure 9B 

Optionallf r the user can specify, in the 
DDEF conmand's BCB operand (or in the DCS 
macro instruction) , that a certain percent- 
age of space be left in each page during 
creation of the data set, for the addition 
of logical records (PAD parameter) . 

Ill buffering required for f ISIl proc- 
essing is supplied by the system. The 
buffer size is one page for data pages, one 
page for work page. 

fISIIf logical records may be for«at-F or 
format-?; detailed descriptions are in Ap- 
pendix C. 

The macro instructions associated with 
processing of virtual index sequential data 
sets are SETL, GET, PUT, IBAD, WIITE, and 
DELIEC. For shared data sets, the ESETL 
and lELEX instructions are provided. 

SETL positions a f IS data set to the begin- 
ning, end, next, previous record, or to 
any specified logical record within the 
data set. If the user wants to specify a 
particular logical record with SETL, he 
may do so by using either the record key 
or the retrieval address. However, for a 
shared data set, a user may not specify a 
retrieval address with SETL. As with the 
fSAH SETL, any attempt to position the 
data set outside its own bounds will 
cause an exit to the user's synchronous- 
error address (SYHAD) . For a successful 
SETL, the record •s retrieval address will 
be provided by the system in the appro- 
priate DCB field. 

GET obtains sequential access to a logical 
record of a VIS data set. It may be 
specified by the assembler user in one of 
two forms: 

Hove Mode — The user provides the sys- 
tem with the address to which he wants 
the record transferred; the system 
moves it. 

Locate Mode -- The user requests the 
address of the next logical record in 
the appropriate input buffer- iith 
this address, he has the option of 
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procressing the record in that location, 
or Boving it to his own work area. 

Again, after each execution of the GET 
macro instruction, the retrieval address 
of the logical record just retrieved is 
available in a data control block field. 



PUl seguentiallf ere 
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the sjstea for con 
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ates logical records in 
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cally ascending 
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f the previous record, 
tect this and exit to 
nous-error routine. 



This macro can be used when the DCB 
has been opened for output, if no other 
BCBs have been opened for output. It can 
be specified in either of two nodes: 

Move Mode — The user provides the sys- 
tem with the address of a logical rec- 
ord, and the system transfers the rec- 
ord from that location to the next a- 
vailable output buffer segment; from 
there, it is automatically written to 
the output data set by the system be- 
fore that portion of the buffer is re- 
leased or reused . 

Locate Mode — The user requests from 
the system the address of the next a- 
vailable output buffer segment; he uses 
that address to store the logical rec- 
ord that he wants to add to the data 
set. The system automatically writes 
the record to the output data set when 
necessary . 

As with VSAE, the ?ISAH POT may be 
used as a means of truncating an already 
existing data set. If any records exist 
on this page beycmd the current position, 
they are deleted one by one until the end 
of the page is reached. If any pages of 
this data set exist beyond this page, 
they are deleted. The directory is also 
truncated as necessary. 

ISAB enables the user to read logical rec- 
ords nonsequential ly, based on a user- 
supplied data key of the retrieval 

address. Since REAB automatically uses 
SETL to position the data set at the pro- 
per record, it has the same limitiaion as 
SETL with regard to record specification; 
logicral records of shared data sets may 
not be specified by retrieval address. 
After selecting a logical record from an 
index sequential data set or member, BEAD 
transfers that record to a user -specified 
location - 

For shared ¥IS data sets, an 
exclusive-lEAD can also be specified by 



this macro instruction. Then no other 
program requesting that record can gain 
any access to it until it is released by 
the user who issued the BEAD macro 
instruction. 

If an attempt is made to read a record 
with a key greater than the last key in 
the data set, the system transfers con- 
trol to the user's end-of-data set 
address. If a READ request is made, and 
the record with the specified key cannot 
be found (but its key is less than the 
highest key in the data set) , or if an 
invalid retrieval address is specified, 
control is transferred to the user's 
synchronous-error routine . 

WRITE creates a fIS data set in a nonse- 
quential manner, or inserts or updates 
logical records in an existing VS data 
set. The three basic functions of this 
instruction are: 

WRITE — Mew key 

WRITE — Replace by retrieval address 

WRITE — Replace by key operation 

WRITS — new key: The system assumes 
that the user wants to add a new record 
to the data set. A search is therefoi^ 
made of the existing data keys in the 
data set; and exit is taken to the user's 
synchronous-error address, if a record 
with an identical key is found. If the 
key is unique, the system automatically 
positions the locator for the record in 
the appropriate position, so that the 
records of the data set will be available 
for retrieval in an ascending key 
sequence. 

WRITE — replace by retrieval address or 
WRITE ~ replace-by-key: The system 
assumes that the user wants to update an 
existing record. If the system deter- 
mines that the retrieval address or key 
specified is not that of an existing rec- 
ord, an exit is made to the user's 
synchronous-error routine. Otherwise, 
the system replaces the old record with 
the new one, adjusts the available space 
if the length of the new record is not 
equal to that of the old (placing the new 
record on an overflow page if necessary) , 
and updates the record locators and main- 
tains the logic:al key sequence. 

For shared FIS data sets, the WRITE macro 
instruction also releases any page-level 
write interlocks placed on the record, 
through the same DCB, by an 

exclusive— READ . 

DELREC deletes a specified record from a 
?IS data set. The user specifies, either 
by key or by retrieval address, the rec- 
ord to be deleted; DELREC uses SETL to 
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locate this record . If the record can 
not be found p- an exit is Bade to the 
sjnchronous-error routine • If SETL 
locates the desired record^ the lo>cator 
for that record is reaoved froB its page, 
the remaining locators are coapressed, 
and the space occupied by that record is 
Bade available for future use. If the 
re€3ord with the lowest key on the page is 
deleted DELREC calls IDE (CZCPL) to up- 
date the directory to reflect the new low 
key on the page. When the last record on 
a data page is deleted DBLEEC will delete 
not only the record but its corresponding 
key entry froB the directory and the page 
froB the dataset. Page is the only 
page which will not be deleted when it 
becoBes empty. When a page is deleted 
froB the dataset not only is its corre- 
sponding key entry removed f roa the dire- 
ctory but all key entries with PPl values 
greater than the page Just deleted will 
be adjusted downward to reflect their new 
PPH in releationship to the dataset. The 
pages old PPH value is also saved in the 
key entry and is used when validity 
checking pages in the input page routine. 
(See Figure 9D.) 

BSETL releases a page-level read interlock 
iaposed by another macro instruction 
(e.g., GET, SBTL or REIB, nonexclusive) 
froB a shared data set. It does not re- 
lease the page-level write interlock set 
by an exclusive-BEAD . 

EBLBX Bakes a record that belongs to a 

shared data set available to other users, 
by releasing the page-level write inter- 
lock set by an exclusive-lEAB. 

YISAM Sharing Rules ; The use of VISA! with 
shared data sets results in setting and 
releasing interlocks . 

BITl SET LEVEL IITER LOCKS — If a VIS data 
set is opened for input, in-out, out-in, 
or update, a read interlock is set for 
the entire data set, preventing other 
users from opening it for output. 

If a VIS data set is opened for out- 
put, a write interlock is set so that no 
other user can open it. 

P10E LEVEL IHTERLOCKS — A read interlock 
is set on a page of a VIS data set re- 
ferred to by a SBTL, GET or IBAB (nonex- 
clusive) macro instruction; OPEH does not 
impose any page-level interlocks. 

A page-level read interlock is re- 
leased by an exclusive-READ, WRITE, 
ESETL, DELREC, or RBLEX macro instruc- 
tion, if issued against the data control 
block that caused the interlock to be 
set. Page-level read interlocks are also 
released when the data set is closed, or 
by any other macro instruction that 
refers to a page other than the current 
page. (for example, a sharer issues a 
READ macro instruction for a record. 
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cattsing a page to be brought into his 
virtual storage; later ^ he issues a EEID 
for a record not on that page. The page- 
level read interlock, set when the first 
lEAD was issued, is released on execution 
of the second •) 

A page-level write interlock is set by 
an exclusive-BEAB, or bj a WRITE macro 
instruction. 

k page -level write interlock is re- 
leased by a GET, READ (nonexclusive) , 
lELEX, WRITE, DEUREC, or CLOSE macro in- 
strucrtion, or by any other macro instruc- 
tions that refer to a page of the data 
set other than the current page- 

firtual Partitioned Access Method — YPAH 

The virtual partitioned access method is 
not an access method in the normal sense of 
the term. ¥PAE contains no routines for 
reading or writing records. A virtual par- 
titioned data set really is a collection of 
data sets that a user has combined for ease 
of reference. These constituent data sets 
are called members; each member is 
organized as a virtual sequential or virtu- 
al indexed sequential data set. The other 
access methods are used to read records of 
a member into a task's virtual storage. 

¥PA1 provides the control that performs 

these functions on members: 

Create or add to a virtual partitioned 
data set. 

Prepare any member of a virtual parti- 
tioned data set for processing. 

Add new members to, or delete existing 
members from, an existing data set. 

Opdate existing members in place. 

Each member of a virtual partitioned 
data set is identified by the name of the 
virtual partitioned data set followed by an 
unqualified member name in parentheses. 

The partitioned organization (see Figure 
10) allows the user to refer to either the 
entire data set or to any member of that 

data set . 

References to individual members are 
made through the partitioned organization 
directory (POD) . When a partitioned data 
set is created, a POD is set up to account 
for each member. As members are added, 
deleted, or changed, the directory informa- 
tion is automatically updated. 

The first entry (one or more pages) in 
the virtual partitioned data set is the 
POD, which is used to locate members of the 
data set. Each member begins on a new 
page; any unused space on the preceding 
page is left open. 



Provision is made for users to assign 
additional names, called aliases, to each 
member, and to locate each member on the 
basis of either its name or any of its 
aliases. The partitioned data set organi- 
zation is suited for storage of libraries, 
where references to different entry points 
may require the loading of the same 
subroutine . 



Example: A partitioned data set named 
HATBLIB, whose members consist of mathemat- 
ical subroutines such as SQRT, ARCTAS, and 
COS, also contains an alias for SQRT, 
called ISQRT; this alias is used to indi- 
cate that the argument is a negative value, 
so an imaginary value is expected. Refer- 
ences to both SQRT and ISQRT would indicate 
the same member, but a different entry 
point may be desired when ISQRT is named 
(see Figure 10) . 



Partitioned data sets may be composed of 
fS or ¥IS members, or a mixture of both. 



All buffering required for fPAH process- 
ing is supplied by the system, based on the 
maximum logical length specified in the 
member's DCB; for a ¥IS member, the work 
areas needed for the ISD or POD are also 
supplied. 

Two macro instructions are associated 
with VFAM: FIID is used to prepare a mem- 
ber for processing ; STOW is used to update 
the POD and, in certain cases, disconnect a 
data set member from a user's problem 
program . 

FIID searches a POD to locate the member 
descriptor of a particular ¥P data set 

member (using either the member name or 
any of its aliases) , and then positions 
the member for processing. This posi- 
tioning includes obtaining member infor- 
mation from the member descriptor and 
transmitting it to the member header in 
the RESTBL and to the DCB that has been 
opened for the data set. 

FIID initially checks the DCB to de- 
termine if it is currently in use. If 

FIHD had been issued previously for a 

member of that data set, and the informa- 
tion in the POD has not yet been updated 

by a STOW for that member, FIID calls 
STOW to update the member information in 
the POD. However, if the DCB is in use 

for the creation of a new member, that 
member may not yet have been named, so a 
STOW could not then be issued for it. 
Therefore, to protect against this situa- 
tion, FIMD will not attempt to issue STOW 
under these conditions, but will return 
an indication to the user that he must 
issue a STOW macro instruction for the 
new member before issuing FIID. 
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Figure 10. firtual Parti tioaed Data Set 



If the DCB is aot in nse, the POD is 
searched for the name given in the PIHD 
■aero instruction. If the nase cannot be 
located in the POD, a not -found return is 
Bade to the user; if the naiie is located, 
sharing data is checked and the member is 
positioned for processing by the appro- 
priate SITL. 



PIID also provides the service option 
of moving user-data from the POD to a 
user-defined area* 



STOl modifies, adds, or deletes member or 
alias descriptors in the PODj the proc- 
essing will depend on the type of STOW 
specified by the user: 

fype I (new) — If the member name is 
not found in the POD, the POD is updat- 
ed to reflect the addition of the new 
member. If the member name is found in 
the POD, processing is ended and a code 
returned to the user indicates that the 
new name is not unigue. 

Type II (new alias) ~ The POD is 
searched for each alias being added | if 
each is unique, alias descriptors are 
created . 

Type 1 freplacel — This type replaces 
user-data and c£Loses the member* If 
■•user area" is specified, the data will 
be stored in the POD. The POD is up- 
dated to reflect any changes made to 
the member, and return is made to the 
user. 



Type D fupdatel — Same as type 1, ex- 
cept that the member header in the 
lESTBL is not closed; it remains active 

for further processing. 

Type D fdelete) — This type causes the 
member to be deleted; all data pages 
associated with the member are deleted, 
and the member and alias descriptors 
are deleted from the POD. The DCB is 
initialized for reuse and control is 
returned to the user. 

Type DI (delete alias) — Deletes 
aliases from an existing member. The 
POD is searched for each alias being 
deleted and its descriptor is deleted 
from the POD. This process is repeated 
for each alias being deleted. 

Types C and Ch (chancre name and change 
alias) — The POD is searched for the 
name or alias being changed. The new 
member name or alias replaces the old. 

fP&g Processing : Since processing a ¥P 
data set usually involves only one member 
at a time, the single DCB opened for a data 
set can be used for the member being pro- 
cessed. For processing existing members, 
PIHD must be issued after the OPEl macro 
instruction; however, when a new member is 
being added to the data set, a DCB is 
opened for either VIP or VSP (depending on 
the type of member desired) , POT or WHITE 
macro instructions are used to create the 
member, and a STOW (type H) is issued to 
include the member in the data set. In 
this case a FIND is not needed. I "FIMD" 
is also not needed when the member name 
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paraaeter of the BDIF coaiand is specified. 
for tliis case, OPBiVlM will issue the 
•*FI1D". When several meabers are to be 
processed siaaltaaeouslf ^r one DCB per Mem- 
ber Must be opened. Tie opening of each of 
these DCBs aust be followed by a FliD macro 
instruction for that member ,► so that the 
appropriate infornation is placed in the 
correct BCB. 



?P data se' s aia 
eaber level wlieE a FIID 

issued; there -.-ire no 
e data set level ^. as 

Member interlocks are 
L w!ie£i FIID is issued; 

the STOW or CLOSE 

Onlf the aember being 
terlock applied; other 
e to other users for 



fPie Sharing Rules ; 
interlocked at the m 

Macro instruction is 
interlocks set at th 
for WSkm and ¥ISA1. 
set within the BISTB 

the J are released by 
fiacnro instructions, 
processed has the in 
aembers are availabl 
processir.q* 

VIS members are: 



write iat«rlockf':dir when opened for output; 

read interlocked^ when opened with any 
other option. 

fS aeabers are: 

read interlock ed .> when opened for input; 

write interlocked^ whea opened with amy 
other option. 



SEQOEITIAL ACCESS HE THOPS 

The seguential access aethods directly 
specify the appropriate channel programs 
and they control the logic of error recov- 
ery, in addition to providing data set aan- 
ageaent. These access aethods generally 
require that the msBr specify a large num- 
ber of functions that are handled automati- 
cally by the virtual access nethods. The 
user also has available to him special- 
purpose routines that enable him to create 
his own Hirect acc^s and tape-volume 
labels • This is not possible with VAM» 

Data sets accessed by the seguential 
access methods are of physical seguential 
organization* They are organized on the 
basis of physical records ^ whose order is 
determined strictly by the order of 
creation • 

The seguential access methods are: 

Basic seguential access method fBSAl) 

Queued seguential access method (QSAl) 

llml.tiple seguential access method (ISAl) 

Terminal access method fTIlII) 

Input/output request facility flOlEQl 



Basic Secfuential Access Method — BSAM 

BSAH provides a limited data set compat- 
ibility with OS by supporting the direct 

access r or unlabeled, or standard labeled 
magnetic tape data set formats (except for 
the direct access split-cylinder format) 
that are produced by the OS basic sequen- 
tial and queued sequential access methods,. 
Alsor BSAH is the primary means r within 
TSS, of accessing magnetic tapes. 



BSAH creates the channel programs that 
seguentially access tapes or disks, and 
passes an I/O request control block 
(lOBCB) , containing the channel program and 
buffer information IT to the resident super- 
visor through a supervisor call. The lOlCB 
format is shown in Figure 11. The resident 
supervisor, in turn, initiates the channel 
program, records any pertinent error infor- 
mation, and passes the lOlCB back to BSAH, 
which then attempts error recovery if nec- 
essary, and informs the user of the results 
of the I/O operation by posting the infor- 
mation in a data event control block 
(BECB) . A DECB is a storage area reserved 
as part of a macro expansion (or reserved 
separately for future purposes by using the 
L-form) that relates an I/O operation to a 
specific BEAD or WRITE instruction. Bach 
BEAD or MUTE requires one DECB that con- 
tains control information and pointers to 
status indicators. 



With BSAl, the user must determine the 
outcome of his request before he can do any 
processing that is dependent on that re- 
guest; the DECB provides a means for making 
the determination* The test for completion 
is made hj issuing the CHECK macro instruc- 
tion. If the I/O operation ends satisfac- 
torily, control is given to the seguential 
instruction following the CHECK macro in- 
struction. If the request results in an 
error or a special condition, control is 
passed to the user^s synchronous-error rou- 
tine (if one was specified; otherwise the 
task is terminated) . If the I/O operation 
is not complete when CHECK is issued, the 
task will wait until the operation is 
complete . 

BSAH creates its own channel programs in 
virtual storage, using virtual storage ad- 
dresses. However, the channels do not 
operate on the basis of dynamic address 

translation, since they can not be made to 
wait for paging in whenever they reference 
a page that is not in main storage. For 
the same reason, all buffer areas that are 
to be referenced during the execution of a 
channel program must be in main storage 
during the entire I/O operation. There- 
fore, the resident supervisor reads the 
lOlCB into its own area. of main storage, 
translates the virtual addresses in the 
channel program into real addresses, and 
passes the lOHCB back to virtual memory 
only when its buffer has been filled. 
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Figure 11. lapnt/Ontpiit Bequest Control 
Block (lOlCB) 

{Placing the lOlCBs in supervisor 
storage serves another function: In gener- 
al, BSIH buffers can be expected to be less 
than one page long* Since supervisor 

storage is allocated in S'l-byte incireaents, 
the ■axiMUB size of an lOlCB can be kept 
within 1920 bftes, thus saving paging over- 
head and Bain storage use.) 

If a buffer is too large to be contained 
within the lOBCB, BSkE places in the lOHCB 

pointers to the pages containing the 
buffer* 

Using BSAM : BSIl enables a user to access 
unblocked physical sequential data sets. 
It also provides access to blocked records; 
all blocdcing and unblocking must be done by 
the user, ihether records are blocked or 
unblocked, BSKE uses the block as the unit 
of data exchange with the problem program. 
BSIH accepts these record formats: format- 
F pilocked and unblocked) , format-f 
f blocked and unblocdced) , and format -U 
{unblocked only) . Descriptions of these 
formats are in Appendix C. 

The system checks the physical lengths 
of blocks containing format-F records and 
transfers control to the user's SYIID rou- 
tine if an incorrect -length block is read. 
The user must then determine the size of 
the block read, froi a count field in the 
BBCB. Iccordingly, the length of format-F 
records must not be changed after a data 
set is opened; the physical attributes of 
format— F records must be accurately 
described. 

Is with all access methods, before a 
user can employ B5M to process a data set. 



he must open the DCB associated with that 
data set. In response to the BSIM OPEM 
macro instruction, the system: 

Finds the matching data definition 

Completes the DCB fields 

Establishes address relationships and 
linkages to access routines 

Issues to operator any required mounting 
messages 

ferifies or creates data set labels 

Positions volumes to the first record to 
be processed {see Table 1) 

Allocates and prepares required buffer 
pools 

Establishes the volume dispositions for 
end-of-volume conditions 

Causes entries to user label checking, 
label creating, or DCB exit routines (if 

supplied) . 

In the CLOSE macro instruction, the 
magnetic-tape volume disposition is 
specified: 

lEHEID — leposition the current volume 
to reprocess its portion of the data 

set. 

LElfB ~ Position the current volume to 
the end of its portion of the data set 

just processed. 

For magnetic tape, the exact positioning 
that follows the CLOSE instruction will 
vary, depending on whether labels are spec- 
ified for the data set. Table 2 defines 
two final-position numbers for labeled and 
unlabeled tapes. These numbers are then 
used in Table 3, which correlates the spec- 
ifications of I/O processing in OPEl with 
the positioning specified in CLOSE. 



BSAH Macro Instruction ; These are in three 
general categories: data-set oriented, 
buffer oriented, and device -control 

oriented. 

Buffering macro instructions ■ — BSIM is 
primarily intended for use on unbuffered 
physical sequential data sets; there is no 
automatic buffering facility. However, the 
user may provide himself with some buffer- 
ing by using the GETBUF, GETPOOL, FREBBDF, 
and FREEPOOL macro instructions. All such 
buffers are only work areas for the user; 
they are not intermediate storage areas. 
Ill input/output operations between these 
areas and external storage are performed 
directly, without using intervening holding 
areas. 
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Table 



Effect of OPEl Optiotts 



I ^ ~ r 

Open Option f De¥ice 



Action 



Initial Positioning 



IMPOT 



Magn etic- tape 



Direct access 



Data set is read segnentiallj, 
either forward or backward 
(depending on what is speci- 
fied in each lE&D aacro in- 
struction) ; labels y if speci- 
fied y are processed as input 

Data set is read forward 
segnentiallj; labels, if spec- 
ified ^ are processed as input 



First data record. 



RDBJkCK 



lagn etic-tape 



Data set is read seguentiallj ^ 
either forward or backward (de- 
pending on what is specified 
in each SEID macro instruc- 
tion) ; labels r if specified, 
are processed as input 



Last data record of 
last ¥oluKe of data 
set. 



OUTPUT 



IIOIT 



Magn etic-tape or 

direct access 



Magnetic-tape or 
direct access 



OPTIl 



Hagn etic-tape or 
direct access 



Data set is written sequen- 
tially; labels, if specified, 
are processed as output 

Data set is read sequentially 
first; labels, if specified, 
are normally treated as input 
(however, if records are writ- 
ten to the data set, subsequent 
labels, if specified, are pro- 
cessed as output) ; when read- 
ing is conpletedy volume is 
repositioned and data control 
block remains open so that 
data set can be processed as 
output 

Initially data set labels are 
processed as output; after 
data set is opened, user nay 
issue HEID or WRITE aacro in- 
structions in any order; when 
end-of -volume is reached, 
labels are processed either as 
input or output, depending on 
whether lEAD or ifilTE macro 
instruction caused end-of- 
voluae condition 



If data set dispo- 
sition is specified 
as lEW or OLD, vol- 
ume is positioned 
to first data rec- 
ord; if data set 
disposition is spec- 
ified as MOD, volume 
is positioned to one 
record beyond last 
data record of last 
volume of data set- 



OPDIT 



Direct access 



Data set is read sequentially; 
blocks can be updated in place 

by output requests that write 
last block read back to data 
set; labels, if specified, are 
processed as input 



First data set 
record. 
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fable 2. ^ Final Magiretic Tape Positions 



1 — 1 ■ "1 " - "" n 

f 1 Labeled Tape | Unlabeled Tape ! 

i 1 1 f 


r 1 1 f 

1 1 1 Preceding data | Preceding first | 
1 f set header label | data block of I 
1 1 group 1 portion of data | 

1 1 1 set resident on I 

I 1 1 current volume \ 

II 1 ■ 


1 f 1 1 

1 2 1 Following tape | Following tape I 
1 1 Mark that ter«i-| nark that termi-l 
1 1 nates trailer- I nates last data | 

I 1 label group f block of portion | 

II 1 of data set that| 
1 i 1 is resident on | 
1 f 1 current volume | 



GlTPOOl requests allocation of a buffer 
pool area, and it assigns that area to a 
specific data control block. The user 
must specify the number of buffers in the 
pool, and their lengths. Only one buffer 
pool may be assigned to a data control 
block at one time. 

GETBUF obtains a buffer from a specified 
buffer pool that must have been prcjvious- 
ly assigned to the data control block ei- 
ther by a GETPOOL macro instruction , or 
as a result of the buffer options speci- 
fied in the DCB macro instruction. Buff- 
ers obtained by GBTBUF must be returned 
by a FBEEBOF, if they are to be obtained 
again. 

FIEEBUF returns (to its buffer pool) a 
buffer obtained by GETBUF. It is not 



necessary to free all buffers prior to 
closing a data set; it is necessary to 
free a buffer before it can be acquired 
again. 

FHEBPOOL releases areas that were previous- 
ly assigned to specified data control 
blocks as buffer pools. The area must 
have been acquired either by the execu- 
tion of a GSTPOOL macro instruction, or 
as a result of buffer options specified 
in the BCB macro instruction. If a FISE-^ 
POOL has not been executed by the time a 
data set is closed, the CLOSE macro in- 
struction will release the area involved. 

Data set interactive macro instructions ; 
REAB, IIITE, CHECK, and DQDECB enable a 

user to: 

Create a sequential data set by storing 
blocks in the order in which they were 
supplied. 

Sequentially add blocks to the end of an 

existing sequential data set. 

Sequentially retrieve blocks from an ex- 
isting sequential data set, or retrieve 
an individual block based on these 
posiitioning capabilities — beginning 
of data set, location of previous block 
processed by system, or location of any 
of data set's blocks. 

Update an existing data set either by 
updating blocks in place, as sequential 
processing proceeds (direct access 
device only) , or by updating blocks in a 



Table 3. Effects of OPEM and CLOSE Options on Magnetic Tape Positioning 



II f 1 FOSITIOIIIIG SPECIFIED | 
f OPTIOl OF 1 OTHEH FICTOIS | DIRECTIOl OF | IM CLOSE f 

1 A1>"PH 1 TWPT riT'WPTlin 1 T B cjl* TWPTTT* L. ,- 1 


f SPECIFIED IS| POSITIOMIHG f OPEIITIOH | LEAVE | lEEEAD | 


1 OUTPUT 1 lone I Mot applicable | Position 2 f Position 1 | 


1 OUTIl I Hone 1 lot applicable | Position 2 | Position 1 | 


1 IIOUT 1 Ho WHITE operation | Backward | Position 1 f Position 2 | 


1 1 data set I Forward I Position 2 I Position 1 | 


1 1 It least one illTE | lot determining factor I Position 2 | Position 1 | 
1 1 operation for this | III 
1 1 data set I III 


1 INPUT 1 Hone I Backward | Position 1 | Position 2 | 


1 1 1 Forward I Position 2 | Position 1 | 


1 RDBACK I Hone | Backward I Position 1 | Position 2 | 


f 1 1 Forward I Position 2 | Position 1 | 
I 1 ■ III 


1 loter Trailer label exits are takcm for data set processed for IHOUT or OUTIH, if 1 
1 last operation was a illTB; no trailer label exits are taken if last operation was a f 
1 IBID. 1 
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nonsequential aanner (direct access 
device only) , or bf reproducing a data 

set to allow the user to insert new rec-- 
ords and/or delete old records as the 
modified copy is being made. 



gmest for a transfer of a 
d, from an I/O device di- 

ecif ic virtual storage 

be recorded in a control 
nd placed on an I/O request 
1 is then returned to the 
when the device is avail- 
able the request is executed. 



EBID causes a re 
physical recor 
rectly to a sp 
input area, to 
block (D1C3) a 
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user •& program ; 



IBITl causes a reque 
physical sequentia 
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positioned to the 



st for a transfer of a 
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to an I/O device (di- 
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equest queue. Control 
o the user's program; 

available, the request 



ue of control blocks 

the requests for read 
s, to determine if 
e been satisfied. It 
ther errors or excep- 
have occurred while 
uest. For each data 
ro instructions must be 

order in which the 
ations were requested. 

nchecked BECBs (created 
d WHITE macro instruc- 
e of unchecked DECBs 
system. This macro in- 
lly used in the SHAD 
pie SEIB or WSITE macro 
been issued without an 
If DQDBCB is issued, 
or WHITE requests must 
user must ensure, be- 
at the data set is 
desired record.) 



Device control macro instructions pro- 
vide a user with physical control over a 
data set: BSP, CITHL, PEOY, POIMT, and 
MOTE. Some of these may be combined with 
the interactive macro instructions to pro- 
vide nonsequential access to a data set, 
within the framework of BSIH. 



BSP backspaces one p 
current magnetic t 
volume . Beg ar dies 
reading (specified 
struction) , or the 
the OPEM macro ins 
is always toward t 
netic tape volumes 
position on direct 



hysical record on the 
ape or direct access 
s of the direction of 

in the READ macro in- 

option specified in 
truction, backspacing 
he load-point on mag— 

or the corresponding 

access volumes. 



CNTRL repositions magnetic-tape. 

FEO¥ positions a multivolume data set at 
the beginning of the next sequential vol- 
ume, before the physical end of the cur- 



rent volume is reached. This macro in- 
struction is not applicable to data sets 
on unit record devices. When volumes are 
switched by this macro instruction, FEOf 
creates the necessary output labels for 
current and new volumes (output data 
sets) or verifies the volume labels for 
current and new volumes (input data 
sets) . In attempt to execute this macro 
before all HEAD and WRITE requests to the 
data set have been checked will result in 
abnormal task termination. 

POUT repositions a magnetic-tape volume to 
a specified physical record within a data 
set on that volume; for direct access 
volumes, POIMT places control information 
in the appropriate control block, so that 
the indicated record will be the next 
accessed. The user must verify that the 
block identification previously provided 
by a HOTE macro instruction (now being 
used in the POIMT macro instruction) 
refers to the same volume. Dsing POIHT, 
in conjunction with the information pro- 
vided by a previous MOTE, permits reading 
or writing a sequential data set from any 
specified position. All read or write 
requests must be checked for completion 
before the POIMT macro instruction is 
executed . 

MOTE makes available to the user the rela- 
tive position within a volume of a phys- 
ical record that has been just read or 
written. This relative position identi- 
fies the block for subsequent reposition- 
ing of the volume. Repositioning is nor- 
mally accomplished by the POIMT macro in- 
struction. All read or write requests 
must be checked for completion before the 
MOTE macro instruction is executed. 

Both the MOTE and POIMT macro instruc- 
tions require that the current block count 
in the DCB be valid. For an unlabeled data 
set, or a data set containing nonstandard 
labels, there are conditions when this 
count may not be valid, since the block 
count is normally found in the trailer 
label. These conditions occur when: 

the DDEF €x>mmand or macro instruction 
specifies a disposition parameter of 
MOD, or 

the OPBM macro instruction specifies 
RDBACK. 

Dnder these conditions, neither the MOTE 
nor POIMT macro instructions should be 
used. 

Practical Applications : A sequential data 
set can be created by using BSAM and speci- 
fying output or out-in in the OPEM macro 
instruction, and by using the WRITE and 
CHECK macro instructions to transfer blocks 
to the data set being created. To add 
blocks to an existing sequential data set, 
the user specifies output or out-in in the 
OPEM macro instruction, and MOD in the DDIF 
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coBaandt to position the sfstem to the end 
of the existing data set. He then issues a 
series of IBITl and CHECK lacro instruc- 
tions to add the physical records. 

To obtain each of the physical records 
of a physical seguential data set in the 
order in which they were written, the user 
specifies input in the OPIH macro instruc- 
tion to position to the first record of the 
data set. He then issues a series of READ 
and CHECK macro instructions to retrieve 
the blocks in sequence. It is also possi- 
ble to retrieve the records of a physical 
sequential data set nonseguentially by 
using the NOTE and POINT macro instructions 
in the manner indicated in their 
descriptions . 

Physical seguential data sets can be 
updated-in-place if they reside on direct 
access storage. When this method is ap- 
plied r the user specifies updating in the 
OPEN macro instruction and then issues the 
appropriate seguence of macro instructions: 
BEAD and CHECK; WRITE and CHECK. Each READ 
and CHECK instruction provides a physical 
record in the user's work area. By examin- 
ing this block (record) , the program can 
decide if it is to be updated. If the rec- 
ord is not to be updated, the program can 
branch to another READ and CHECK instruc- 
tion to examine the next block. If a block 
is to be updated, the program does that and 
then issues WRITE and CHECK macro instruc- 
tions to return the just -read block, or its 
replacement, to the data set. {Only the 
most recently read block, or its replace- 
ment, may be updated and returned.) If two 
WRITE and CHECK macro instructions are is- 
sued without an intermediate READ and 
CHECK, the second WRITE overlays the first. 

Queued Secrtiential Access Method 

The queued seguential access method 
(QSAH) consists of the TSS data set manage- 
ment fai^dlities that enable a user to> 
access physical seguential data sets at the 
logical record level. QSAH, in contrast to 
BSAW, permits the user to store and retri- 
eve logical records of a seguential data 
set without coding his own blocking/ 
deblocking and buffering routines. Osing 
QSAl, a seguential data set can be stored 
on, or retrieved from, disk or tape. 

QSAl's basic functions are blocking and 
deblocking logical records, issuing I/O re- 
quests, and checking and positioning data 
blocks- QSAM itself blocks, deblocks, and 
buffers internally, but uses BSAM to per- 
form I/O operations such as reading, writ- 
ing, and checking and positioning for 
access to data. 

Blocking Logical Records : QSAl blocks log- 
ical records according to the logical 
record— length and block-size parameters 
found in the DCB. When a user wants to in- 
clude a logical record in an output data 
set, he issues a PUT macro instruction. 



QSAH adds this logical record to the phys- 
ical record (block) currently being built 
if it will fit within the current buffer. 
If it will not fit, the block is considered 
complete, and the record for which the PUT 
was issued will be treated as the first 
record of a new block. The user can cause 
a block to be prematurely regarded as com- 
plete by issuing a TRUNC macro instruction. 

Deblocking Logical Records ; QSAi returns a 
single logical record to the user each time 
he issues a GET macro instruction. When 
the current block has been completely pro- 
cessed, the next GET instruction causes the 
buffer to be refilled, if the data set was 
opened for input or readback, or to be 
written back before refilling, if needed, 
when the data set was opened for updating. 
At any time, the user can cause processing 
of a buffer to be regarded as complete by 
issuing a RELSE macro instruction. Follow- 
ing this, the next GET macro instruction 
will retrieve the first logical record from 
the next physical record. 

Buffering Blocks of Data ; Double buffering 
is the normal buffering facility of QSAl. 
This involves the use of two buffers, one 
of which will be in use while I/O activity 
is being performed on the other. Thus, on 
a normal input or readback data set, while 
logical records from one buffer are being 
^ipplied to the user, the other buffer is 
being refilled. On a normal output data 
set, QSAM will continue adding logical rec- 
ords to one buffer while the other is being 
written out. 

Under some circumstances, it is neces- 
sary to perform only single buffering; only 
one buffer is used. The decision to use 
double or single buffering is based on the 

OPEN option of the data set and on the 

macro option specified in the DCB. Double 
buffering will be done in all cases except 
when the data set is opened for updating, 
or SETL has been specified in the DCB. 

Single buffering must be done on an up- 
date data set to allow the user to update 
one block of records at a time. lO' 
reading-ahead can be done until there is a 
determination on whether the current block 
of records must be updated, since an update 
WRITE instruction can return only the last 
block read. When the user specifies the 
SETL macro instruction, he must be able to 
specify it after QSAM finishes checking any 
individual physical I/O operation; single 
buffering is therefore a necessity. 

Double buffering on a readback data set, 
with fixed or undefined length records, is 
handled in the same manner as for an input 
data set, except that blocks of records are 
read beginning with the last block of the 
data set. However, if a data set opened 
for readback specifies variable-length rec- 
ords, the procedure includes the use of a 
third buffer. After a block of records has 
been read and checked, a copy of it is 



Accessing Data Sets 33 



ao¥ed to tke third buffer. This copf is 
used by the system as a table to contain 
recx>rd lengths, so that the records in the 
actual buffer may be accessed in reverse 
order. Mote that, although three buffers 
are used, this is still only double buffer- 
ing; the third buffer is, in a sense, a 
duRDy. 



Psinq QSAM : QSIM enables the user to 
access blocked and unblocked physical 
sequential data sets • The records within 
each such data set can be format-P (blocked 
or unblocked) , format-? (blocked or 
unblocked) , or forma t~U (unblocked only) . 
These formats are described in Appendix C. 
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Table 3. (lote: in- 
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As the user requests input or output of 
logical records, QSAM anticipates the need 
for I/O activity, manipulates buffers, and 
performs any deblocking or blocking that is 
required • The user is free to concentrate 
on processing of logical record streams, in 
and out of his program. 

QSAM Macro Instruction s; Is with BSIM 
macro instructions, these are in three gen- 
eral categories: data-set oriented, buffer 
oriented, and devioe -control oriented. 

Data— set oriented macro instructions en- 
able a user to: 

Create a sequential data set by sequen- 
tially storing its logical records in 
the order they are supplied by the user. 

Sequentially add logical records at the 
end of an existing physical sequential 

data set. 

Retrieve logical records from an exist- 
ing physical sequential data set, or 
retrieve an individual record, based on 
these positioning capabilities: 

beginning of data set on current 
volume, 

end of data set on current volume, 

previous logical record on volume 
(backspace) , 

or a record whose retrieval address 
was previously obtained. 

Opdate an existing data set by updating 
logical records in place as sequential 



processing proceeds (direct access 
only) . 

The QSAM macro instructions are: SETL, 
GIT, POT, and PUTX. 

SETL enables a user to logically position a 
physical sequential data set at its be- 
ginning, end, at the previous logical 
record, or at any user-specified logical 
record. Subsequent PUT or GET operations 
will start at the specified position. 

GET reads logical records in sequential 
order; unless it is used in conjunction 
with SETL, when the order is not neces- 
sarily sequential. GET may be specified 
in either locate or move mode. In locate 
mode, GET locates the next sequential 
logical record of a data set, reads it 
into a buffer if necessary, and places 
its address in register 1 « The user may 
then operate on the record in the buffer 
where it is located or he may move it to 
his own work area. In move mode, GET 
acquires the next sequential logical rec- 
ord from a buffer (reading it into the 
buffer if necessary) , and moves it to a 
user-specified work area. 

PUT writes new or altered logical records 
into a physical sequential output data 
set. PUT may be specified in either lo- 
cate or move mode. In locate mode, PUT 
places in register 1 the address of an 
output buffer. The user should subse- 
quently construct, at that address, the 
next logical record to be incorporated in 
an output data set. The system will au- 
tomatically write the physical record, of 
which the logical record is a member, 
into the data set. In move mode, the PUT 
macro instruction moves a logical record 
from a user-specified work area into an 
output buffer, so that the system may in- 
clude the record in the output data set. 
The user must ensure that the length of 
the logical record is in the proper DCS 
field before executing this macro 
instruction . 

PUTX causes the next logical record in a 
buffer area of an input data set to be 
written as the next sequential logical 
record of an output or update data set. 
PUTX may be specified for either output 
or update mode. For update, the input 
and output data sets are one and the 
same; PUTX merely indicates to the system 
that a given logical record in a buffer 
associated with that data set is to be 
written back, in its present form, to the 
data set; for output, the input and out- 
put data sets are distinct; PUTX trans- 
fers a logical record from the buffer of 
the input data set to a buffer of the 
output data set, from which it is to be 
written out by the system. Note that 
PUTX (output mode) is effectively the 
same as PUT (move) ; in fact, the PUT 
macro instruction accomplishes this func- 
tion more efficiently than PUTX. The 
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Buffer-oriented macro instractions # 
TlUC and IILSE, give the nser some control 
over sfstem inpmt and output for his data 
sets. 

TllWC causes the current output buffcir to 
be regarded as filled, so the system will 
transfer the truncated physical rec%ird in 
that buffer, as it then stands, to the 
data set on the €»tput device. The sys- 
tem is then positioned at the next buffer 
area, which will be used to hold the next 
logical record supplied, by the user, for 
output* If an attempt is made to execute 
this macro instruction when the output 
buffer is already full, or when the rec~ 
ords are unblocked, the instruction will 
be ignored. Therefore, effective use of 
this macro always results in a 
nonstandard-length block being written to 
the data set • 
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Device control-^oriented macro instruc- 
tion * FEOf. 

FBOV directs the system to advance to the 
next volttB,e of a data set before reaching 
the end of the current volume* It also 
ensures that the last buffer is written 
out to an output data set, and that any 
anticipatory requests to read, issued by 
the system for that volume but not yet 
checked, are purged. As in BS&l, when 
volumes are switcAed by this macro in- 
struction FIO? creates the necessary out- 
put labels for current and new volumes 
foutput data sets} , or verifies thcs vol- 
ume labels for the current and new 
volumes (input data sets) • 



Fractical Applications ; A physical sequen- 
tial data set can be created, using QS AM, 
by specifying output in the OPEN macro in- 
stru€rt:ion, and by using FOT macro instruc- 
tions to transfer logical records to the 
data set being created. When the last rec- 
ord in the data set has been created, the 
user issues a CLOSE macro instruction. 
This writes the remaining output buffers, 
discsonnecrts the data set from the problem 
program, and takes care of any label writ- 
ing and volume disposition that may have 
been specified. 



The user can add logical records to an 
existing physical sequential data set by 
specifying output in the OPEl aacro in- 
struction and modification fM^OD) in the 
DDE! command; this positions the system to 
the end of the existing data set. He then 
i^ues a series of POT macro instructions 
to supply the additional records. When all 
the additional records have been trans- 
ferred, he issues a CLOSE macro 
instruction. 

The logical records of a physical 
sequential data set may be retrieved in the 
order in which they were created. The user 
specifies input in the OPEI macro instruc-- 
tion to position the system to the first 
record of the data set^ and then issues 
successive GET macro instructions to re- 
trieve the logical records. ihen end-of~ 
data is detected during a GET, the system 
transfers control to the user^s end-of~data 
routine. Logical records may also be re- 
trieved nonsequentially from a sequential 
data set by preceding the GET macro in- 
struction with either the EELSE or the SETL 
macro instruction. The use of these macros 
has been previously explained. 

The user may update physical sequential 
data sets in place, after specifying update 
in the OPBl macro instruction, by employing 
the PlTl macro instruction (update mode) • 
First, he issues the GET {locate) macro in- 
struction to determine the address of the 
next sequential logical record. By examin- 
ing this record, the user can determine if 
he wants to update it. If it is not to be 
updated, a branch is made to another GET 
instruction, to examine the next record. 
If a record is to be updated, the appropri- 
ate changes can be made to it, and then a 
PUTl (update mode) macro instruction should 
be issued to return the updated logical 
record to its original storage location in 
the data set. 



lultiple Sequential Access Method 



HSAH 



HSAI consists of the data management fa- 
cilities that enable the user to process 
logical records at the GET/PUT m.acro- 
instruction level for the IBM 25«l0 card 
reader/punch and the IBM 1403 printer. 
HSAl is a fast and efficient mechanism for 
simultaneously driving several unit-record 
devices under the control of a single task; 
ISAI also has automatic buffering and 
error-retry options. 

ISAM differs from the other sequential 
access methods (such as BSAi) • For each 
ISAM I/O request, the system processes a 
buffer group of physical records; for each 
BSIi. I/O request, the system processes only 
one physical record. Considerable process- 
ing is required in the supervisor and the 
access methods for each I/O request, 
regardless of buffer size. Usually M.SAM 
will, make an I/O request only once to proc- 
ess each buffer, even though the buffer 
will contain a large number of physical 
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records; this is acconpliskel bj ckaiiiiiig 
the channel commantl words (CCls} related to 
each physical record in the buffer. 
Sfstea-processiag overhead will thereby be 
mininized when using unit -record eguipBent. 

ISIl also differs froM the other seguen- 
tial acjcess methods because several data 
sets may be grouped on one device ^ allowing 
the user to process all of then under the 
same BC3. This saves hia fro» issuing OPEN 
and CLOSE Macro instructions for the BCB 
every tiae a data set with different char- 
acteristics is to be processed. Each data 
set is a data group« Input data groups may 
be separated by control cards ^ which MSIl 
will recognize and whose presence will be 
coMBunicated to the user; he «ay then take 
whatever action is necessary. Output data 
groups on the card punch aay be separated 
by the special cards that are autoaatically 
merged froa the card reader, or the data 
groups »ay be physically removed froa the 
stacker by issuing a message to the opera- 
tor. The merging can be accomplished by 
specifying the COMBIM option in the DCB 
aainro instruction; the removal, by issuing 
the FIIISH macro instruct ion • 

Bach buffer used by ISAM (a buffer group 
of physical records) occupies one page of 
virtual storage. The number of buffer 

pages assigned to any DCB is based on the 
device with which the DCB is associated, 
determined individually by the specific 
installation by a parameter in the symbolic 
device allocation table (SDIT) . This 
allows the value for a devicre to be 
adjusted so that the device will be driven 
full-speed for the maximum time between two 
consecutive tiae slices. 

The first 32 bytes of each buffer page 
are reserved for control information used 
by ISll- The remaining portion of the page 
is packed with logical records. The maxi- 
mumi number of such records per buffer page 
is 100 on input and 200 on output; depend- 
ing on the size of the records, there may 
be fewer. 

ISll is well suited to the time-shared 
environment because it transfers responsi- 
bility for waiting for I/O completion from 
system service routines, such as BSIf! 
check, to the invoking routine. Waiting 
for I/O while time-sharing is particularly 
undesirable during a user's time slice; a 
built-in wait-state is provided at time- 
slice-end. Therefore HSm provides the fa- 
cility for processing DCBs that are ready 
to be processed, and for skipping those 
that the user finds to require waiting. 
When all opened and accessed DCBs require 
waiting, the task may wait for the first 
I/O interruption associated with any DCB in 
the task. 

Psinq HSllI s ISIH enables the user to 
access blocked and unblocked physical 
j^guential data sets, when the data sets 

are associated with unit-record devices. 



Within each such data set, format-F and 
format-V records are permitted (see Appen- 
dix C) . 

The DCB defined for data sets that are 
to be accessed using HSAK includes a number 
of special fields (including the COMBIII 
field previously mentioned) that are not 
part of the DCBs generated for any other 
access method. When the user opens the 
DCB, the common portion of the OPEN routine 
completes the portion of the DCB that is 
common to all access methods, and then 
invokes the access-aethod-dependent OPII 
routine. This routine allocates the re- 
quired number of buffer pages, and allo- 
cates and formats an lOHCB and a DECB for 
each buffer page that it allocates. The 
DECB is not generated at assembly tiae, as 
it is in other access methods. 

When he has finished processing a data 
set with the KSll macro instructions, the 
user issues the CLOSE macro instruction for 

that DCB. In response, the system returns 
all fields of the DCB to the conditions 
they were in before opening, issues the 
PimSH macro instruction (explained below) , 

and releases the areas of storage obtained 

by the access-aethod-dependent portion of 
the OPIM macro instruction. 

MS&M macro instructions are: SETDB, 
GET, POT, and FIWISH. 

SETOE specifies the physical configuration 
of the unit-record device associated with 
the DCB for which this instruction is is- 
sued. When necessary, the system writes 
a message to the operator to notify him 
of the configuration he is to provide. 
Between repetitions of this macro in- 
struction, the user must interrogate the 
DCBICB field of the DCB and, if it is 
non-0, invoke the interruption-inquiry 
routine by using the IITIHQ macro in- 
struction (described in Assembler Use r 
Macro Instructions ) to determine whether 
an asynchronous interrupt is pending. If 
yes, the user must give control to the 
appropriate interruption -handling routine 
before reissuing SETUl. 

GET obtains the next sequential logical 
record from an input buffer and may be 
specified in either the locate or move 
mode. In the locate mode, GET locates 
the next sequential record in the speci- 
fied input data set, and places its 
address in register 1. In the move mode, 
GST locates the next sequential record in 
the specified input data set and moves it 
to a user-specified work area in virtual 
storage. The GET macro instruction of 
ISAH differs from GET in other access 
methods in the action taken when a 
referenced input buffer is not yet full. 
Instead of going into a wait state, HSAH 
returns a code to the user indicating 
that no record has been provided since 
the next sequential buffer has not yet 
been filled. To obtain that record, the 
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user ■ust reissue the GEf instrmction; 
Beanvkile , ke may perforn otker work. 

PUT iaclndes a record in aa output buffer, 
the contents of wkich are to be printed 
or punched on unit -record equipment. 
This macro instruction may be specified 
in either the locate mode or the moTe 
mode. When specified in the locate mode, 
POT returns, in register 1, the address 
of an area within an output buffer. In 
this area, the user may construct a log- 
ical record which will automatically be 
included, by the system, as the next 
sequential record of the output data set. 
Vhen specified in the move mode, POT 
mowes a logical record from a user- 
specified location to an output buffer; 
from there it will automatically be writ- 
ten as the next sequential record of the 
output data set. PUT returns to the user 
a code indicating the manner in which the 
instruction was completed. In I/O-not- 
complete indication informs the user that 
there was not enough room in a free buff- 
er to include the logical record; he may 
reissue the POT later, and, if a buffer 
is then free, the system will indicate by 
return code that the POT was completed 
sucxressf ully . Again, it will automati- 
cally be written as the next sequential 
record of the output data set. 

FIIISH signals the KSIH routines that proc- 
essing has been completed for the current 
data group (the cairrent subsection of the 
data set) . Employing this macro instruc- 
tion, users can process data groups that 
have different attributes but are under 
the control of the same DCB, without 
closing and opening that DCB between data 
groups. EIHISH initiates the final writ- 
ing of buffers for an output data set, 
and tests the results of all outstanding 
I/O operations for both input and output 
data sets. To avoid having his task 
placed in a wait-state, the user should 
issue PIIISH for a data set before issu- 
ing CLOSE. Bather than allowing the user 
to test for I/O completion, HSIH CLOSE 
will place the task in the wait-state un- 
til I/O activity is completed {ISIM CLOSE 
is the only MSAM routine that will do 
this) . Another reason for issuing FIMISH 
before CLOSE is to ensure notif icaition of 
I/O errors on final I/O operations; CLOSE 
does not provide this facility. If the 
user receives a notification that I/O op- 
erations have not been completed, he may 
continue with other processing, and reis- 
sue flllSH at a later time. FIHISl also 
will notify the operator to remove the 
current data group from the devices; or it 
will automatically separate data groups 
being punched with cards from the card 
reader funder control of the COMBIHE 
field of the DCB) . 

MSAM Error Processin g; Provides the user 
with an automatic error-retry option, under 
the crontrol of the DCB. Example: The DCB 
may specify that a print error be hsmdled 



by striking out an erroneous line and 
attempting to print it again. The system 
will, if it is unable to recx>ver from an 
I/O error encountered as a record is being 
processed, return an indication of this to 
the user; he can then determine whether the 
error was permanent. If permanent, the 
user should issue a CLOSE instruction for 
that DCB; if the error was not permanent, 
the user may continue processing records 
beyond the one with the error, by reissuing 
the macro instruction. For an input opera- 
tion, he may even process the record with 
the error, since he will have a copy of it; 
however, the validity of that record will 
be doubtful. 



Input/Output Request Facility 

The input/output request facility 
(lOlEQ) consists of the data management fa- 
cilities that enable users to program their 
own I/O device-control routines. In 
effecrt, lOlEQ is not an access method, but 
a means by which the user can create his 
own specialized access methods. 

The user of lOEEQ creates channel com- 
mand words fCCls) and executes them as he 
desires. Since the user of lOREQ can have 
complete control over a device, and possi- 
bly monopolize the channel to which the 
device is attached, the use of lOKEQ is re- 
stricted to devices defined as private in 
the symbolic device allocation table 
(SDAT) . Also, only the BULKIO task and E 
class users can request the allocation of a 
specific private device through a symbolic 
device address. 

Because of the direct level of contact 
between this facility and the devices them- 
selves, the user of lOlEQ must: 

Be thoroughly familiar with how the 
device interfaces with a channel through 

its control unit 

Handle all exceptional conditions 
through his SHAD routine 

leissue all outstanding requests if an 
I/O request is unsuccessful (perform his 

own error recovery) 

lot exceed the maximum number of concur- 
rent I/O requests for this device (spec- 
ified in the SDAT) . 

The parameters for the channel program 
and buffer address, in an 101 CB associated 
with each I/O request, must be explicitly 
defined by the user in lOlEQ. While this 
places a greater burden on the user than in 
other access methods, it also provides him 
with greater flexibility. Example: He may 
specify a buffer located in an lOFCB, or in 
a user work area; or he may write channel 
programs that use CCW chaining and he may 
perform scatter-reads or gather-writes 
(reading or writing data into or from vir- 
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Psing IQREQ : Is with the other access 
methods, the user must open a data set be- 
fore using lOlEQ to access it; a CLOSE 
macro instruction must be issued to discon- 
nect the data set from the system. 
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When the CLOSE instruction is issued, 
the task is put into the wait-state until 
all outstanding I/O requests have been com- 
pleted; then all storage allocated during 
open-processing is freed, and the normal 
close-procedures are completed. 
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lOlEQ initiates a sequence of I/O opera- 
tions that are specified in the previous- 
ly generated list of virtual channel com- 
mand words. lOlEQ uses this list as 
input for generating a list of channel 
command words (CCWs) to be placed in the 
lOlCB for execution by the appropriate 
channel. lORCBs are executed separately 
by the channel, unless the user specifies 
lOlCB chaining in the appropriate field 
of the VCCW. (Mote: This is not the 
same as the fCCW chaining accomplished 
within the lOHCB.) lOlCB chaining is al- 
lowed only between lOBCBs that are on the 
same device. Even though lOlCBs may be 
chained, separate CHECK macro instruc- 
tions must be issued for each lOlEQ re- 
sult, because each lOREQ generates a 
separate DECB. 

If buffering is specified for an 
lOlEQ, the size of the buffer within the 
lOlCB for read-request fCCWs is determin- 
ed by the difference between the lowest 
and highest data -area addresses specified 
in any read-request ¥CCW within that ¥CCW 
list; some data areas may overlap. 
Therefore, the user must ensure that a 
contiguous entity is formed by the indi- 
vidual data areas referenced by each 
read-request YCCW in the list associated 
with that lOlEQ. 

The size of the buffer built for 
write-request ¥CCWs is determined by the 
SUM of the individual data areas associ- 
ated with each ¥CCW; that is, unique 
buffer space is allocated for each write- 
request ¥CCW, regardless of whether the 
data areas referenced by these ¥CCWs have 
overlapping portions. Consequently, the 
data areas associated with write-request 
¥CCWs do not need to form contiguous 
areas. 

When buffering is specified in lOlEQ, 
data is moved from user data areas to 
output buffers within the lOlCB before 
any I/O activity is performed for any of 
the write-request ¥CCls within the ¥CCW 
list. Therefore, although a user may 
chain ¥CCWs that are to read into a par- 
ticular data area and then write from 
that area, the sequence of operations 
will result in the old, not the new, data 
being written, as the user might expect. 

If buffering is not specified in 
lOlBQ, the area within the lOlCB that 
would normally have been used for the 
buffers is used instead for page-list 
entries to the user's data areas. Then 
the data transfer is directly between the 
channel and these areas. 

CHECK tests for completion of an lOlEQ 

macro instruction, and detects errors and 
exceptional conditions. CHICK must be 
used for every lOlEQ issued; and must be 
issued in the same order as the lOlEQs. 
If an exceptional condition is detected, 
control is passed to the user's SYIID 
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routine (whicli Must be provided or an 
IBE»D will be executed) . If the I/O op- 
eration is successful, the user's program 
resumes execution at the instruction fol- 
lowing the CHECK instruction. 



TERilMAL ACCESS MEfHQD — YAM II 
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TAMU is composed of five distinct com- 
ponents. They are: 

1. ITAi - leal Terminal Access Method 

This component resides in the super- 
visor and is an interface between 
the TSS supervisor and the device 
modules (DCMs; see below) 

2. DCM - Device Control Modules 

The DCMs provide all device depen- 
dent support reguired to do the fol- 
lowing functions: 

a. builds channel programs and 

initiates I/O 

b. Baintains line control during 
non-activity between user and 
task 

c. handles device dependent timer 
routines 

d. validates task I/O reguests 

e. handles device dependent PCI re- 
guests and non -normal completion 

status 

f . handles the connection of a 
device to a task whether initi- 
ated by the user or the task 

g. sets up device dependent infor- 
mation in the reguired system 
control blocks 

h. provides error recovery for all 
abnormal endings 

i. checks user^s input for user 
function reguests (cancel , at- 
tention, etc.) 

J. determines length and type of 
input 



k. provides simple output edit 

capability for system messages 
to the terminal user. 

3. VTSS - ¥irtual Terminal Support 
System 

This component resides in the task^s 
virtual memory, validates the re- 
guests, and translates the program's 
reguest against the user's environ- 
ment. After determining what has to 
be done, VTSS will call the correct 
format control module (FCH) to for- 
mat the data if any for the user's 
terminal. 

i>. PCM - Format Control Modules 

The PCM performs the reguired edit- 
ing and/or formatting reguired by 
both the terminal device and the 
user. The PCM also ensures that the 
reguest is setup in a mode that the 
next level of TAMII will understand. 
The PCM then calls the module or 
access method, either in real core 
or virtual memory, reguired to do 
the actual reguest. The PCM pro- 
vides the following functions: 

a. edits output data 

b. translates output data to line 
code 

c. invokes correct routine to do 
I/O 

d. translates input data to EBCDIC 
from line code 

e. edits input data 

f . moves input data to correct data 
area (user's or GATE'S) 

g. sets up correct return code 

h. performs any reguested valid 
control functions 

i. maintains correct seguence and 
buffer links for buffered re- 
guests in virtual memory 

j . performs any special task 

initialization reguired for con- 
necting device 

5. TCS - Terminal Command Subsystem 

TCS handles all device command re- 
guests and maintains the terminal 
environment control blocks. 

Onlike other acccess methods, TAMII does 
not use DCBs and JPCBs; the primary control 
blocks are a TCT (Terminal Control Table) 
entry for ITAH and the FCL (Pomat Control 
Library) entry for ?TSS. At the time the 
terminal is connected to the system, a TCT 
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is allocated and constructed. When the 
terminal is connected to a task a FCL is 
allocated and constructed by VTSS . Both 
the TCT and the FCL contain device informa- 
tion and areas to be used for work areas . 
For coMiBttnication between ?TSS and RTAff the 
ATCS SVCr with an associated parameter 
list, is used to initiate or request a 
function to be performed at the terminal. 
When ETAM communicates with VTSS^ it is 
through a special I/O synchronous interrupt 
processor . 

Tin II also will use other access methods 
to fulfill the program •s request. Since 
TAMII is the access method used to read and 
write SYSIS and SISOOT non-conversationally 
TAIII has to be able to access datasets. 
flMII does this by using the appr opiate 
access method for the dataset. TIMII sup- 
ports ?AH and QSIH and can read and write 
datasets with DSOlGs of PS, VI and ¥S. 

TIIII allows both queued and direct con- 
trol of the terminals by the application 
program. The application program may also 
transmit EBCDIC character strings, in which 
case TAIIII handles all editing and transla- 
tion, or the program can bypass the TAMII 
character facilities and transmit direct 
terminal control information. 

Through appropiate default values, TIIII 
allows the task owner to control the queu- 
ing funcrtion independently for both input 
and output, transparent to the application. 
This allows the application programmer 
greater control over the testing of his ap- 
plication program. 

TIMII assumes all responsibility for 
error recovery. When the application 
issues a request, TAMII assumes the respon- 
sibility of getting the request to the ter- 
minal. For output, under normal condi- 
tions, the application does not receive a 
completion notification if the write com- 
pletes successfully. 



Osinq TAMII 

TAMII is used bot 
the application prog 

issues the appropiat 

macrros. Currently t 
grammer is unable to 
tion of a terminal t 
there is no ■OPEH* m 
minal user has to in 
by entering a ■BEGIl 
nal and then the app 
the connection reque 
macros are available 
programmer and the s 
the terminals: 



h by the system and by 
rammer when either 
e GATE or T-GATE 
he application pro- 
initiate the connec- 
o the task. Therefore 
aero as such. The ter- 
itiate the connection 
• command at the termi- 
lication is informed of 
St. The following 

to the application 
ystem for controling 



1. CHCKT - check a DECB for completion 

of a request. 

2. DIAL - dial a terminal through an 
autocall mechanism. 



3. EXLIST - activate, deactivate termi- 
nal exit list entries. 

4. FINDQ - poll and locate work for an 
application. 

5. SETTEBM - allows user to set, reset 
and interrogate flags and fields in 
the TAMII control blocks. 

6. SOLICIT - solicit data input from a 
terminal by using an increasing num- 
ber prompt or a decrement count of 
lines. 

7. TCLEAl - purge active and pending 
I/O requests for a terminal. 

8. TCNTRL - initiate a control request 
for a terminal. 

9. TDCMD - execute a string of device 
control commands for a terminal. 

10. TFIEE - release a terminal from the 
task and the system . 

11. TGATID - read an input line from the 
pending input queue or the terminal. 

12. TGATWS - write a message to the 
user's primary SYSOUT. 

13. TGATWE - write data to a terminal 

14. TGTWAB - write data and read any a- 
vailable input from a terminal. 

15. TGTWSB - write a message to the pri- 
mary SISOOT and read the user's 
response from the primary SYSia. 

16. TRCBUF - read a line from the con- 
versational buffer for the terminal. 

17. TWRTLST - write a list of output to 
the terminal. 

18. TEBMPIO - set up or save a terminal 
user's environment. 

19. TIANLCD - locate a translate table 
for a terminal. 

Three macros which allow an application 
to push and pop a terminal's environment 
and pending queues after an attention from 
the terminal user are: 

1. ATTHSAf - save the current terminal 
environment and pending queues. 

2. ITTIEST - restore a previously saved 
terminal environment and pending I/O 
queue. 

3. ATTNDST - destroy a previously saved 
entry . 

For application proqrams, supporting 
multiple terminals and/or users, four 
macros are available to setup the terminal 
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c^ntiDols and control the teralnal 
coimactloiis: 



!• HTT - inform and setup coEtrol 

blocks €x>iinecti2ig terainals to a& 
application when the request is ini- 
tiated bj the terainal user. 

2. ITTDCi - disconnect and discontinue 
the sultiple terminal application 
program . 

3. ILOGOl • inhibit user initiated 
connections • 

*!• FlOGOl - penit user-initiated 
connections • 

T1.1II provides five ways for an applica- 
tion program to be informed of the comple- 
tion of a request or of the receipt of an 
asynchronous interrupt; they are: 

1. Bevice »EXIf LIST* - when the exit 
list condition occurs, the routine 
identified by the exit list is 
scheduled to receive control. 1?his 
list is device specific. 

2. Ipplication program general •EXIT 
LIST* - a list general to the pro- 
gram. When a device condition 
occurs which the device exit list 
does not have an entry for, the ap- 
plication program's general list is 
checked and if it has an entry, the 
routine is scheduled for execution. 

3. The system SIl and BIB with SIEC and 
S&EC (synchronous I/O and asynch- 
ronous I/O interrupt) queuing 
mechanism is supported by TAIII. If 
there isn't an exit list entry, the 
FIHDQ work table is marked and an 
interrupt is queued by calling the 
Task Monitor. 



lote ; iteis 1 through 3 above all 
result in an asynchronous call to 
the application's routines. 

i|. FIIDQ work polling capability - the 
application may process completions 
synchronously to execution by issu- 
ing the FIIBQ macro when the program 
is ready to receive interrupt and 
completion notification. 

5. CHCKT - Til II 'check' capability, 

using the techingue of assigning a 
DECB to a request and later issuing 
the TllII CHCKT macro for the DECB 

to determine if the request has com- 
pleted. With the TIMII CHCKT func- 
tion an application program can spe- 
cify whether a wait is to be done if 
the I/O has not completed. 

Ill Tim macros are keyworded and most 
of them use the same keywords and return 
the same return codes to help the user in 
coding. When supporting multiple ter- 
minals, the most important keyword is the 
•OSl'. This keyword is the application's 
way of telling TIHII which terminal the 
program is communicating with. 

Tim has a common return code set for 
its macros. This helps the programmer in 
using the TIMII macros. 

Code Explanation 

successful call 

4 terminal is busy (request queued) 

8 attention received on this request 

12 request aborted attention pending 

16 request purged by TCLEIR request 

20 end of data received for SOLICIT 

2^ user error in parameter list 

28 input not available for TGITID 

32 requested operation not supported 

on this terminal 

36 terminal disconnected from system 

10 permanent error on request 
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FIBT III; 



OSE OF DATA MAMAgEHEirT FACILITIES 



Tke user of TSS May kave no direct use 
for aaiif of the data aaaageaent facilities. 
Interfaces are provided to request for hiii 
specific data ■anageoent routines that will 
perform specific services. 

Although assembler users normally have 
the Bost^ direct contact with data aanage- 
aent facilities because they eaploy the 
macro instrucrtions of the access methods, 
usually they cannot directly access ter- 
minals using BTAE; some use the GATE macro 
instruirtions as interface when they need 
the ITAl facilities. The BTT-mode macro 
instructions (see Part II, under »»ETA1'») 
provide this interface for multiterminal 
tasks. 

All users can employ the command system 
to create, access, and modify data sets; 
the c:ommand system, in turn, requests the 
facilities of the appropriate access 
method • 

I/O routines of the FORTRAl and PL/I (F) 
libraries provide the interface between the 
€x>mpiled code and the system's data manage- 
ment routines for FORTH AM and PL/I (F) 
users. 



ASSEMBLER IHTERFACES 

The nonprivileged assembler user has no 
direct communication with either unit- 
record equipment or terminals from within 
his problem program. However, he can 
indirectly access unit-record equipment, 
and his own terminal, by means of the bulk- 
output facilities and the GATE macro in- 
structions. Bulk-output facilities are 
much the same as those in the command lan- 
guage. See "'Command System Interfaces," 
next in this part. 

The GATE macro instructions allow the 
nonprivileged assembler user, from within 
his problem program, to write to his own 
S¥SO0T, to read from his own SYSIM, or 
both* Depending on whether the task in 
which they reside is conversational or non- 
conversational, the GATE routines call on 
TAIII or fAH to accomplish their functions. 



The GATE routines process any required 
writing by dividing the message into 
device-sized lines, or smaller; then the 
appropriate access method is determined and 
used to transmit the message to SISOUT. 

When reading is required, the GATE rou- 
tines determine the appropriate access 
method and use it to obtain the input mes- 
sage; they apply a predefined character- 
translation table to the message as it is 
transmitted to the user's buffer. 



The GATE macro instructions ; 
GATIR, GTIAR, GTWRC, and GTISI. 



GATRD, 



GATED reads a record from a SlSIl device, 
translates it to internal code, and 
places it in a user-designated area of 
virtual storage. 

GATWR translates a record that is stored in 
a user-defined area, and writes it on a 
SfSOOT device. 

GTWAR translates a record that is stored in 
a user-defined area and writes it on a 
SYSOUT device; then it reads a record 
from the SISI¥ device and places that in 
another user-defined area of virtual 
storage . 

GTWRC processes in the same manner as 

GATWR, except for nonconversational SYS- 
ODT records, in which it translates a 
record and a carriage-control characrter 
that is stored in a user-defined area, 
and then passes it to a SYSOUl device. 

GTWSR (for conversational tasks only) 

translates a record that is stored in a 
user-defined area, and writes it on a 
SYSOOT device; then reads a record from 

the terminal and places it in another 

user-defined area of virtual storage. 

ICAST is an assembler macro instruction 
that allows the user to replace the 
character-translation table with one of his 
own choosing; this new table will be used 
by the GATE macro instructions for the 
duration of the task, to translate data 
transferred between the user's program and 
SYSm or SYSO0T. 
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COHH&ID SYSTEM IHTElflCES 



Tlie coBaand sfstan uses the basic data 
»aiiage«eiit facilities to get a broad range 

of data manageMeiit ser¥ices; the user can 
enter, aanipulate, oatpat, and copy data 
sets; he can enter and delete data set 
catalog entries, and he can utilize the 
catalog-sharing facilities described in 
Part II • 

There are five categories of coamand 
sjstea data-Banage»ent services: 

Text-^editor services 
DITJL-co«mand services 
Bata"-set copying services 
Bttllc inpEt/otttput services 
Data—set cataloging services 

Details on the interfaces that will be 
outlined here can be found in the Coimand 
System User^s Guide * 



TEXT BBITQR 

lith the text editor, the user can cre- 
ate or alter a virtual index sequential 
(¥IS) data set* It interfaces with the 
GITS and VISll routines to perform the re- 
guested data management services. 



The VIS data sets 
upon by the text edi 
or line data sets, 
indexed by a key con 
a region name and a 
names, arranged alph 
data set into region 
the elements of eacii 
ber is a seven -digit 
beginning of each re 



created and operated 
tor are either region 
1 region data set is 
sisting of two fields, 
line number; region 
abetically, divide the 
s; line numbers index 
region. The line num- 
decimal number at the 
cord. 



k line data set is indexed solely by 
line number; although it can be thought of 

as a special class of region data set (with 
a null region name) , line and region data 
sets have different maximum record Icingths 
(see Ippendix C for record formats) . 

The text editor commands : EDIT, COi- 
TEXT, COBIECT, EXCmPT, EXCISE, IMSEIIT, 
LIST, M>CITE, iraiBEl, RBGIOl, HEVISE, and 
UPDITB. 

EDIT invokes the services of the texit edi- 
tor. If the u^r has not previously de- 
fined, by issuing a DDEP for it, the data 
set named in this command, a text editor 
routine will automatically issue a DDEP 
with a standard set of operands. In this 
case, the DDHIIE issued for this data set 
will be EDD»nnnn, where nnnn is a number 



that is automatically incremented within 
a task for each new DDIIIB issued, to 
preserve uniqueness. 

If the data set to be edited exists, 
or has had a DDBF issued for it, it must 
be a VIS data set, or a fIS member of a 
virtual partitioned data set. The user 
will be prompted if either of these con- 
ditions has not been met. Ilso, he will 
be prompted if the data set is read-only, 
since it is assumed that he wishes to 
alter it. 

Ifter a JFCB has been created or 
located for the data set, the DCB associ- 
ated with the data set will be opened; 
the DCB is located within a module of the 
text editor. If the data set is parti- 
tioned, the user»s entry of a member name 
is verified. If none was entered, the 
user is prompted and an exit is taken; if 
a member name has been entered, a FIID 
macro instruction is issued for that mem- 
ber. If the member is new, an entry is 
made in the POD by the STOW macro in- 
struction; if the member exists, a check 
is made to ensure that it is virtual 
index sequential. Ifter all initializa- 
tion, return is made to the command mode 
for further text editor commands. 

COITEXT replaces a specified character 
string with an input character string, 
wherever it occurs within a given range 
of lines. Ifter checking the input for 
validity, COITEXT issues a fISIl SETL for 
positioning at the first line with in the 
specified range; then it issues a GET for 
that line (record) . The line is checked 
for occurrences of the specified string, 
which is replaced if found. After the 
line has been completely searched, it is 
written out by a VISIH IIITE, if any 
replacements were made. SETL is then is- 
sued for any necessary repositioning, and 
GET is issued for the next record. This 
process is repeated until the range of 
lines has been completely checked. 

COBIECT makes corrections to a line or a 
range of lines within an object data set. 
If only one line is to be corrected, the 
COKIECT routine uses GITWE to print that 
line, before correction, on the user^s 
SYSOUT« The VISIM SETL and GET macro in- 
structions are used to obtain that line 
and subsequent lines from the object data 
set. Then the SYSIl macro instruction is 
used to obtain the user's corrections 
from his SISIl. I new line is con- 
structed in an output buffer, based on 
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these corrections, and the flSIH WEITl 

(replace-by-key) is used to write the 
line back to the object data set. 

EXCERPf incorporates a portion of a line or 
region data set into the line or region 
data set currently being edited. On 
entry to this routiner the data set to be 
sampled is opened • Ibnoraalities la 
opening (e.g.^ data set not fo-imdr or not 
WIS data set or data set aeMberj result 
in user proapting; an error-exit will be 
taken. If the data set was opened suc- 
cessfully, ¥ISIM SETLs and GBTs will be 
used to obtain the records to be incor- 
porated, starting with the specified (or 
defaulted) first line* The lines will 
then be renuaberM (that is, their keys 
will be changed) ; using WIITE (new key) , 
the resultant lines will be written out 
to the data set l»ing edited. If the 
IBVISE command had been specified previ- 
ously, indicating that the lines being 
excerpted are replacing existing lines, 
the previously existing lines already 
will have been deleted by lEVISE, so 
there will be no key conflict with WHITE 
(new key) . (See also BB¥ISE cojiBand.) 

EXCISE deletes a line or a range of lines 
fro® a line or region data set, VISIl 
SETL and GET are used to position to the 
desired line within the data set being 
edited; then DELIEC is used to delete the 
record by key. 

IISEIT prepares the text editor to accept 
data lines for insertion following a 
given line in the source data set. The 
STSIM macro instruction obtains the input 
data froa the user»s SISIM. 

LIST places a line or a range of lines on a 
user's SYSOUT. Lines of a region or line 

data set are retrieved with a VISAH GET 
■aero instruction and listed on the 
user»s SYSOUT with a GITWE macro 
instruction. 

LOCITE searches a specified range of lines 
in an object data set for a specified 
characrker string. flSAH SETL and GET re- 
trieve the lines within the range sequen- 
tially, until the specified string is 
found within a line; then GITWB, prints 
the line with that string on the user®s 
SYS00T« 



renuffibering; the changed records are 
placed in an addition list froa which 
they will be placed in the object data 
set by a ¥ISiH WRITE (new key) . 

BEGIOl prefixes a region name to a line 
number or range of line numbers; the 
lines so prefixed form a region data set 
and their keys consist of the combination 
of the region name and line number. 
Since the region name is a part of the 
record key, and seven characters of the 
key are reserved for the line number, the 
key length specified in the DCB for the 
data set being edited must be greater 
than 7, to allow room for the region 
name, which will be truncated to fit if 
necessary. (The key length parameter is 
computed and inserted as part of the EDIT 
processing; it is computed as the sum of 
7 plus the value of the REGSIZE parameter 
in the user"s profile.) The user will 
receive an error message if he attempts 
to provide a region name within a data 
set whose key length is not greater than 
7. The SETL macro instruction positions 
to the next available line in the speci- 
fied region; for a new region, this will 
be line 100. 

REVISE prepares the text editor to accept 
data for inclusion, at a given point, in 
the object data set. It accomplishes 

this by first deleting all existing lines 
within the specified range, using the 
¥ISI1 DELIEC macro instruction, and then 

positioning the data set at the beginning 
of the range; the user can then enter re- 
placement lines. The user will be 
prompted if an attempt is made to enter 
more lines than the range allows. 

OPBATE prepares the text editor to accept 
new or replacement data lines, from the 
user's SYSIl, that are to be placed in 
his object data set. The SYSIM macro in- 
struction is used to read the data; if 
the records are not variable length, they 
are padded with blanks as needed. OPDITE 
then checks the key supplied by the user 
at the beginning of the record (if no key 
was provided, the user will be prompted) . 
If a line with that key exists in the 
data set, the record is written to the 
data set with a ¥ISIH WRITE (replace-by- 
key) ; otherwise, a ¥isiii WRITE (new key) 
is used. 



lUiBER renumbers a range 
region or line data set 
associates a new key wi 
within the range. HUMB 
(locate mode) to obtain 
the specified range; as 
ed, they are placed in 
to be deleted (by key) 
macro instruction. The 
changed to conform with 



of lines within a 
; in effect, this 
th each record 
ER uses ¥ISIH GET 
the lines within 
they are obtain- 
a deletion list, 
by the DELREC 
keys are then 
the specified 



SER¥ICES OF THE DATA COHHAID 

The command system's data-editing serv- 
ices allow the user to build and edit both 
¥S and ¥IS data sets. The DATA, MODIFY, 
and LINE? commands are in this group. 
MODIFY and LIMB? are used only with ¥IS 
data sets, and interface primarily with 
VISAM routines; DATA is used for ¥IS and ¥S 
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data sets, and interfaces with, both fSIl 
and WISAE. 

DITI creates either a ¥IS line data set or 
a ¥S data set; also it allows the nser^ 
dnring the creation of a line data set^ 
to dfnaBically insert, delete t and 
replace lines in that data set. 

Ifter validating its input paraweters, 
DITI verifies that a JFCB exists for the 
named data set (that is, if the user has 
issued a DDEF for that data set). If it 
exists, the JFCB aust show either that 
the data set is a virtual partitioned 
data set, or that it has ?S or ?IS organ- 
ization; if either of these conditions is 
not net, an error message will be issued 
to the user. If a JFCB does not exist 
for that data set, DATA will create* one 
bf issuing a DDEF; in this case, the data 
set name and organization are as speci- 
fied in the input parameters, and the 
data definition name is derived from a 
value maintained bj the system for this 
purpose . 

DATA now opens the data set and, if it 
is partitioned, issues a FIND macro in- 
struction to ensure that the member name 
is unique. Ill further processing 
depends on the type of data set being 
created, VS or VIS. 

For a ¥S data set, the SYSIl macrro in- 
struction prompts the user with a number 
sign and retrieves the record from the 
user's SYSIH . Input records continue to 
be read until one is found containing ei- 
ther a %1, or an underscore followed by a 
command; either of these signal the* end 
of input. 



For a ?IS data 
prompted for input 
number. Another d 
must check input r 
indicators; if DAT 
by a line number, 
deleted from the d 
the DEXIEC macro i 
number preceded by 
text following the 
a replacement or a 
depending on wheth 
specified exists i 
exists, a fISAH WH 
issued; if the lin 
exist, a VISAM IRI 
As for a VS data s 
dicated either by 
by a command, or b 



set, the user is 

with the current line 
if ference is that DATA 
ecoris for modification 
A finds a %D followed 
the line indicated is 
ata set being built by 
nstruction. If a line 
only a % is found, the 
% is written either as 
s an insertion line, 
er the line number 
n the data set. If it 
ITE (replace-by-key) is 
e number does not 
TE (new key) is issued. 
et, end-of -input is in- 
an underscore followed 
y a record containing a 



ihen an end-of-input indicrator is 
reached, DATA closes the opened data set 
(a STOI instruction is issued for the 
member, if it is a virtual partitioned 



data set) and then passes control to the 

proper routine. 

If an attention interruption is re- 
ceived while the DATA command is in oper- 
ation, further processing depends on 
whether the data set has been opened. If 
it has not been opened, DATA merely 
returns control, leaving the JFCB set up 
if one was generated. If the data set 
has been opened, DATA closes it (issuing 
a STOI instruction for the member if it 
is a VF data set) and then returns 
control . 

MODIFI inserts, deletes, replaces, and 
reviews records in a VISAM data set or 
flSAM member of a VP data set. Also it 
may be used to build a new VISAM data set 
or member. In contrast to the data sets 
operated upon by the DATA command, IIODIFI 
may be used with VISAM data sets that are 
not line data sets. This is possible 
since the user may specify, as part of 
the MODIFY parameters, an arbitrary key 
length and displacement, as well as 
record -format indicators. 

After input parameters have been vali- 
dated, MODIFY searches for a JFCB for the 
named data set. If none exists (that is, 
no DDEF has been issued for the data 
set) , a JFCB will be created for it. In 
either case, the JFCB must show that the 
data set is either a VP or VIS data set, 
and that the user may write on it. 

Ihen the JFCB is located or created, 
the data set is opened. If the data set 
is partitioned, a FIID macro instruction 
must be issued for the specified member 
name. If the name is found, a check is 
made to ensure that the data set has ¥IS 
organization; if it is not found, a new 
member is created with this name and with 
VIS organization. 

Input records containing the user's 
modifications are obtained, one at a 
time, by the SYSIH macro instruction. 
The user-supplied key points to the loca- 
tion of the specified record. When the 
user-input does not indicate deletion or 
revision, the record is written into the 
data set as an insertion or replacement, 
using either WHITE (replace-by-key) or 
WRITE (new record) . When the first 
character supplied by the user is D, the 
record at the specified location is 
deleted from the data set by the DBLKEC 
macro instruction; when the first 
character is R, the record is reviewed 
(presented to the user) , by the GATWB 
macro instruction. If review of all 
modifications is requested, the record 
that is being replaced or deleted will be 
presented to the user before the modifi- 
cation is made; for insertions, the 
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reccord iaaediately preceding tke inser- 
tion is presented. 

When the end~of -input record is 
reached^ the data set is closed; for a ?P 
data set, the STOW macro instruction is 
issued to reflect any alterations before 
the data set is closed. 
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tents of specified 
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set. (k list data 
line data set; eac 
set has a unique 1 
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Ifter all indicated lines have been 
processed, the data set is closed (if it 
is a VF data set, a STOi instruction is 
issued for the m^iber) , and control is 
returned. 



DATA SET COPYING SERVICES 

The command system provides facilities 
for making additional copies of existing 
data sets; depending on the particular com- 
mand he selects, the user may also be able 
to change the medium on which the data set 
exists. The data set copying commands: 
¥T, TV, VV, and CDS. 

VT copies a data set that is in one of the 
VAl organizations (VS, VIS, or VP) to 
magnetic tape, as a physical sequential 
data set. There is no simple correspond- 
ence between the records of the VAH data 
set and the records of the physical 
sequential data sgt. lecords of the 



physical sequential data set created by 
this command are blocked into page-length 
segments, regardless of the record sizes 
in the original data set. Therefore, it 
would be futile to attempt to use one of 
the sequential access methods (for exam- 
ple, BSAM) to obtain the records as ori- 
ginally placed in the virtual storage 
data set. The user can employ the TV 
command (described below) to copy the 
data set back to a direct access device, 
at a later time, and then access it with 
one of the virtual access methods . 

Initially, VT checks that the input 
data set is a VAl data set. If there is 
no JFCB for the indicated input data set 
name, one will be created. For the out- 
put data set, the user must have created 
a JFCB (with a DDEF) that has a data 
definition name (DDNAHE) of DDVTOUT. VT 
locates this JFCB and verifies that it 
indicates the proper data set organiza- 
tion (physical sequential) and the proper 
device type. 

When the data sets are opened, the 
JFCB of the input data set and the common 
portion of the input data set^s forma t-E 
DSCB are written as the first record on 
the output tape. The remainder of this 
record is padded with O's. 

Data pages to be copied from the input 
data set are located through its BBSTBL. 
For each of these pages, the system's 
paging mechanism is used for input; each 
page is then written to tape by BSAH 
WIITE. Eight buffers are used to overlap 
processing time and input/output time. 

After the tape operation has been com- 
pleted, both data sets are closed and all 
buffers are released. Unless specified 
otherwise, the output data set is cata- 
loged and any JFCBs created by ?T are 
released. 

TV retrieves and writes into a virtual 
storage volume, a data set previously 
written on magnetic tape by a VT command. 
TV verifies that the input data set has 
physical sequential organization and that 
it resides on a tape volume. If a JFCB 
for the input data set cannot be found, a 
DDEF is issued to create one. A check is 
then made that the output data set name 
indicates a new data set, with a virtual 
storage organization. If an output JFCB 
is not located, one is created by issuing 
a DDEF. The user must issue a DDEF for 
the output data set only if he wants it 
to reside on a private volume . 

After the data sets have been opened, 
the first record is read from the input 
set (see "VT," above, for content) , to 
verify the tape format, and make availa- 



46 



him tkm DSCB data necessary to recreate 
the origiaal data set. Data records from 
tlie tape are iapat by BSIl REID and out- 
put (to tke direct access device) hj ?SIM 
POT. It this tise, the data set is being 
treated as VS^ with page-length records, 
regardless of hov it was originally 
created by the nser. For these opera- 
tions, eight buffers are used. The ini- 
tial instructions to read tape fill the 
eight buffers; subsequently, four buffers 
at a tiae are filled as the other four 
are emptied, to overlap processing time 
and input/output time. 

Ifter all instructions for the input/ 
output operations have been issued, both 
data sets are closed and all buffers are 
released. If the output data set, on di- 
rect access storage, is not completed 
correctly, the command-system ElISl rou- 
tine is called to delete the partial data 
set. If the output data set has been 
completed correctly, the DSCB now associ- 
ated with this data set must be modified, 
since it now reflects the organization of 
the data set as it was created by VSIM 
POT (with page-size records and VS organ- 
ization) • To correct this DSCB, the 
format-E DSCB that is part of the output 
data set is read in by TV, and the DSCB 
for the newly-created data set is updated 
from the information in the old one. The 
DSCB then reflects the structure of the 
data set as it was originally created by 
the user. 1 catalog entry for the output 
data set is created if required; any 
JFCBs created by T? are released. 

f makes a copy of an existing fll data 
set; the copy will also exist as a VS 
data set. Initially, VV verifies that 
the input data set name is the name of a 
¥11 data set. If the user does not issue 
a DDIF for the specified data set name, 
there will not be a JFCB for it. I JFCB 
will be created by a call to DDEF fa 
catalog entry, to act as an input source, 
must exist for the data set if a JFCB is 
to be created) . The output data set name 
must indicate a new VIH data set. Igain, 
if no JFCB exists for this output data 
set, one is crreated by a crall to DDEF. 
The user needs to create a JFCB for the 
output data set only if he wants it to 
reside on a private volume. 

When both data sets have been opened, 
the common portion of the input data 
set's format-E DSCB is retained for 
recreating the data set structure aifter 
the copy opera ticm has been completed. 
Data pages to be copied from the input 
data set are located by indexing through 
the lESTBl; the system^s paging facil- 
ities read these pages. They are then 
written to the output data set with a 
¥SI1 POT; at this point the output data 



set is being treated as a VS data set, 
with page-size blocks. 

When the copy is complete, both data 
sets are closed and all buffers are re- 
leased. If the output data set has not 
been completed correctly, ElASE is called 
to delete the partial data set. For nor- 
mally completed VV operations, the output 
data set's DSCBs reflect the structure of 
the data set as it was created by VSIH 
POT (VS struct ure, page-size records) . 
Therefore, the DSCB is updated from the 
DSCB information retained from the origi- 
nal data set, so that structure of the 
data set is shown as it was created by 
the user. The catalog is updated, if 
necessary, and any JFCBs created by VV 
are released. 

CDS copies a data set, or member of a VP 
data set; it may also copy members of a 
partitioned data set (with user data and 
aliases) into a second VP data set, 
replacing or ignoring duplicate members. 
CDS provides the user with the option of 
specifying that the original data set (or 
member) be erased after duplication; he 
may also renumber a line data set while 
copying it. 

Initially, operands are checked for 
validity, and a JFCB is obtained or 
created for the input and output data 
sets. If the input and output data sets 
are both VP and no member name has been 
specified, multiple member processing 
{copying members with user data and 
aliases, if they exist) is assumed. 

For multiple member processing, three 
DCBs are opened; one for input, one for 
VSIH output, and one for VISA!! output. 
If no member names have been specified 
for the input data set, then every member 
found in the input data set's POD will be 
copied. Otherwise, only the members 
specified will be copied. A FIHD for a 
member is done, which fills in the input 
DCB and obtains the user data for the 
member. The output POD is searched to 
see if a member with the same name 
exists. Then each alias in the input POD 
which is associated with the member is 
checked in the output POD. If a dupli- 
cate alias is found, it must be associat- 
ed with the same member name in the out- 
put POD or processing of the member is 
ended. If no invalid duplicate aliases 
are found, and the user has not specified 
that duplicate members are to be ignored, 
the input member is copied into the out- 
put data set using the appropriate output 
DCB . When the copy is complete, the 
input member is erased if applicable, and 
the output member is added to the output 
POD with its user data and aliases, using 
STOW. Hultiple member processing is corn- 
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When processii^ is complete, the DCBs 
are closed and the input data set is 
erased, if specified (not applicable to 
multiple member processing) . Control is 
then returned to the calling routine. 



BPIK IHPOT/DPTPOf SgR¥ICES 

Because of the suitability of public 
storage for the operating environment of 
TSS, users may often want to transfer data 
sets that are on cards or tape volumes to 
public WkE volumes. Alternatively, some 
may want to write data sets to tape, punch 
them on cards, or print them on the instal- 
lation's high-speed printer. Some of these 
functions can be accomplished by using the 
data set copying services. Other options, 
notably those involving unit-record 
devices, are performed using the command 
system's bulk input-output services. These 
services consist of the PRIMT, PUWCH, RT, 
or WT ciommands, together with the operator- 
assisted card input facility. The user can 
issue only the commands associated with the 
output of data sets (PRIHT, PUNCH, and WT) . 
The system operator must initiate the 
others • 



Bulk Output ; When t 
or PUWCa command, th 
on the nature of the 
or punched. Private 
died by the PRIIT an 
lined below, and a s 
tional task will be 
pose. Public data s 



he user issues a PRINT 
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data set to be printed 
data sets will be han- 
d PUNCH routines out- 
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created for this pur- 
et printing and punch- 



ing will be handled by the BOLKIO task. 
This will not be described here. The WT 
command routine, described below, is used 
for both public and private data set writ- 
ing. VSIM and ¥ISI!! are used for opera- 
tions on ¥S and VIS data sets, respective- 
ly; BSkE is used to control tape I/O, and 
ISIfi is used to access unit-record devices. 

PRINT will print an existing private phys- 
ical sequential, virtual sequential, or 
virtual index sequential data set, on an 
installation's on-line high-speed print- 
er. If a physical sequential data set is 
being used for input, it must be on a 
tape volume. Since a physical sequential 
data set can be allotted to only one task 
at a time, and the nonconversational task 
created by PRINT will require it for 
input, specifying a physical sequential 
(PS) data set to be printed will result 
in the release of any JFCB for the data 
set within the task which issued the 
PRINT. Also, if a PS data set is not 
cataloged, it will be automatically cata- 
loged when PRINT is issued; it will be 
erased when the nonconversational PRINT 
task is completed. 

On initial entry to the PRINT routine, 
this command determines the devices to be 
used and the input data set organization; 
it issues BDEFs for the input and output 
data sets, opens these data sets, and 
obtains any buffers that will be needed. 
The ISAH SET0R macro instruction is is- 
sued so that the printer has the required 
device configuration • 

After setting up an identifying output 
line, PRINT obtains input records by an 
internal buffering technique (using VSIB 
or ¥ISII! GETS, and BSAM WRITES and 
CHECKS) , and writes them to the printer 
with internal buffering (using MSAK POTs 
and INTINQs) . PRINT continues to loop in 
this manner, until the last record has 
been printed; then, it indicates any rec- 
ords that were received in error on the 
task«s SYSOOT. The input and output data 
sets are closed, and the nonconversation- 
al task is finally logged off. 

PUNCH is used to punch a cataloged VS or ¥1 
private data set into cards on an instal- 
lation's high-speed punch. When the non- 
conversational task created by this com- 
mand receives control, it calls BDEF to 
define the input and output data sets; it 
then opens each of these data sets, and 
issues an HSAH SETHR for the punch (out- 
put data set) , to ensure that the proper 
card form is mounted. One logical record 
at a time is then read, by VSIH or VIS&M 
gets; after each record is read, control 
options are tested, and the record is 
written to the output buffer with MSIM 
POT. This reading and writing continues 
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iiatil all input re 
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umber of error records, 
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IT writes an existing ?S or flS data set on 
tape, for eventual printing on a high- 
speed printer, fhe output data set is 
automatically formatted into print lines, 
the format required for high-speed print- 
ing. After the operations necessary to 
log on the non conversational task, WT 
calls DDEF to define the input and output 
data sets, and opens these data sets and 
output buffers with a BSAH GETBUF macro 
instruction. A blank line is constructed 
to provide for initial page positio>ning. 
The first record is obtained with a VSAII 
or VISAM GET. An internal buffering rou- 
tine writes the records to the output 
data set, using the BSAM WIITE and CHECK 
macrro instruc±ions . After all input rec- 
ords have been read and written onto 
tape, the output buffers are released, 
the input and output data sets are 
closed, and, if requested, the output 
data set is cataloged. WT then writes on 
SYSOUT the number of records read, writ- 
ten, and skipped, and the number of error 
records. Then LOGOFF is called to termi- 
nate the task. 

Bulk Input ; If the user has data sets on 
tape or cards that he wants to have read 
into the system as bulk input, he must sub- 
mit them together with any required infor- 
mation to the system operator, who will 
then enter and catalog them under the 
user's ID (userid) . 

IT is issued by the system operator, on be- 
half of a user, to read a physical 
sequential data set from tape, convert it 
to a VAH organization (VS or VIS) , write 
it to a public ?AH volume, and catalog it 
in the user's catalog. ¥IS data s€»ts 
will be built as line data sets. 



ihen the syst^i 
this command, it c 
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operator to mount 
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is ready to proc:ess 
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ins input buffers with 
nstruction. Input rec- 
n internal buffering 
s the BSAH BEAD and 

The records are then 
he VSAM or VISAM POT; 
ata sets, the record 
umbers are inserted. 



the output data set is cataloged (in the 
user's catalog) , and the input buffers 
are released with the BSAM FIEEBUF ma€:xo 
instruction. Then the record counts and 
an end-of-task message are written to 
SYSOUT, and LOGOFF is called to terminate 
the nonconversational task. 



OPBEATOB-ASSISTED CARD IIPPT 

The user can submit his data sets on 
punched cards to the system operator, who 
will then enter them into the system 
through the installation's high-speed card 
reader. Two types of input are permitted: 
non -conversational SYSIM data sets, and 
data-card data sets. The two types may be 
interspersed in any order within a batch of 
cards. No command is necessary to read the 
cards into the system; control over the 
reading of these card data sets is part of 
the function of the bulk I/O task . 

A SYSII data set contains all commands 
needed to run a nonconvers^^tional task. 
When one of these data sets is read in, it 
becomes the SYSIH data set of a nonconver- 
sational task, with the submitter's user 
ID. It will be executed as soon as space 
is available. After execution, the SYSII 
data set is eliminated from the catalog and 
system storage. 

A data-card data set contains any infor- 
mation the user wants read into public 
storage as a cataloged data set. As it is 
read, a virtual storage data set is created 
in public storage and cataloged in the 
catalog of the user who submitted the data 
set. It will reside in storage until it is 
specifically erased. (For details of the 
formats of both card data sets, see Command 
System User's Guide . 



DATA SET CATALOGING SERVICES 

The command system gives the 
facility to explicitly request 
log entry by created, altered. 
The commands for these purposes 
LOG, DELETE, and EVV. The ERAS 
in addition to freeing all dire 
storage assigned to a specified 
deletes from the user's catalog 
associated with a data set. 



user the 
that a cata- 
or deleted. 

are : CATA- 
E command, 
ct access 

data set, 

the entry 



When all input data has been read, the 
input and output data sets are closed. 



CATALOG creates or alters catalog entries 
for specific data sets. The user can 
also create a data-set superstructure, 
called a generation data group (GDG) , to 
exercise catalog control over future 
structural elements (generations) . 

This command can be used to change a 
data set name in an existing catalog 
entry for both VAM and physical seguen- 
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DELETE removes a data set entry from a 

user's catalog. An entry for any private 
data set can be removed with this com- 



mand. The original catalog entry for a 
public data set, however, cannot be 
deleted; this is a protection against the 
system "losing** the data set (unlike a 
private data set, the JFCB for a public 
data set does not contain enough informa- 
tion to locate the data set) . The sharer 
of a public data set may delete the entry 
in his catalog; however, the data set 
owner's entry is not affected (the 
sharer's entry consists only of pointers 
to the owner's catalog entry) . If the 
owner of a public data set attempts to 
delete his catalog entry, he will receive 
a diagnostic message; no action will be 
taken . 

EV? catalogs all the VAH data sets on a 
private VAM volume. The system's paging 
facilities are used to read in the DSCBs 
associated with each data set on the vol- 
ume; as each is read in, the data set as- 
sociated with it is cataloged, based on 
the information in the DSCB. When proc- 
essing is completed, the private device 
that was required for mounting the pri- 
vate volumes is released. 
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FQITBAM & PL/I fFI IITEBFACES 



FOITIII users of fSS have little direct 
contact with the sfstea,*s data managemeiit 
facilities « Thef ffiust issue a DBEF for any 
data sets (except SI SIN and SYSOOT) that 
they expect their program to access ^ and 
thef anst specify in the BDEF a data 
definition naae (of the form FT^xFyty ) • 
Beyond that, the FORTlAl library modules 
provide the aajor data oanagement inter- 
fai^e; within these, the I/O control module 
(CHCIC) is the primary point of interac- 
tion. (k description of how the FOITRIH 
user of TSS specifies data set character- 
istics is in FORfRM Procrrammer's Guide ^ 
GC2e-2025*) 



FQRTRIH I/D CQITRQL 
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RBID obtains a logical record from a user- 
specified input source by using the REID, 
GITRD, or GET macro instruction. 

IRITE initializes writing a logical record 
by establishing pointers to the output 
buffer area. Subsequent output process- 
ing is performed by using the IIITB, 
GITll, or PUT macro instruction. 

REillB repositions the user-specified vol-- 
ume of one or more data sets to the first 



record of the first data set by using the 
POINT or SETL macro instruction . 

BICKSPICE repositions the user-specified 
data set to the previous logical record 
by using the MOTE, POINT, SITL, and BSP 
macro instructions. 

EIDFILE defines the end of the user- 
specified data set by using the WRITE and 
STOW macro instructions. 



PL/I CFI IITERFICES 



Like FORTRIl, PL/I (F) provides library 
modules that greatly simplify the use of 
the system's data management routines. The 
user need only issue DDEFs describing each 
data set, other than SfSIl or SYSO0T,. that 
he expects his programs to access, and fol- 
low PL/T fF) language reguirements for 
specifying data characteristics. (PL/I (W) 
Programmer's Guide and PL/I CF) Language 
Reference Manual tell how to specify data 
characteristics from within the PL/I (F) 
language.) 

For the DISPLII statement, library 
module IHBIDSP is a direct interface be- 
tween the compiled code and the GATE macro 
facilities* For STIEIM I/O, there is no 
single interface with compiled code; the 
type of STREIH I/O statement being executed 
determines which library module is invoked 
by compiled code. Bach STREAM I/O state- 
ment finally invokes module IHEWIOF to 
issue the macro instruction. For RECORD 
I/O, the single interface with compiled 
code is module IHEWIOII, which interprets 
the I/O request, verifies its validity, and 
calls the library module that issues the 
appropriate macro instruction. 

Table 4 summarizes the PL/I (F) inter- 
face with data management. 
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Table ft. PL/I (FJ Interface Witli Data Haaagement 



r 1 

1 TIPB 
1 OF I/O 


1 1 
1 FILE 

1 DECLARITION i 


ACCESS 
METHOD USED 


■■ ' " ■ 1 

f MODULE ISSUING | 
MACRO INSTRUCTION 


PL/I I/O 
STATEKENT 


1 

MACRO 1 
INSTRUCTION f 


1 DISPLIY 

I 

t 




TAMII 


' IHEWDSP 


DISPLAY 


GATWR and/or | 
GATED 1 


1 

1 STREAM 




QSAM, 
VSAB, or 
TAMII 


IHEWIOF 1 


GET 


GET (move mode) | 
or SYSIN 1 


1 


PUT 


PUT (move mode) | 

or GATWR 1 

t 


I" 

1 RECORD 


1 COHSECOTIVE, 
f SEQUEHTIAL, 
1 BUFFERED j 


QSAM 
or 

¥SAM 1 


IHEIITG 


READ 


GET 
(locate 


mode) 1 




IRITE 


PUT 
(locate 


mode) I 




LOCATE 


PUT 
(locate 


mode) 1 
I 




REWRITE 


PUTX 1 




1 CONSECUTIVE, 
1 SEQUEMTIAL, | 
1 OH BUFFER ED 


BSAM 


IHEMITB 


READ 


READ 1 


1 


WRITE 


WRITE 1 




REWRITE 


WRITE 1 


1 
1 


1 INDEXED, 
f SEQUENTIAL, 
1 BUFFERED or 1 
1 OK BUFFER ED 


VISAM 


! IHEWITD 
1 (for format- 
IHBWITN 
(for format- 


1 
-F) 
-V) 


READ 


ESETL or SETL | 
to position, I 
GET 1 
(locate mode) | 
to read | 




> WRITE 


1 PUT 
(locate 


f 
mode) 1 


1 


LOCATE 


PUT 
(locate 


mode) 1 




REWRITE 


1 

[ WRITE 1 


1 


DELETE 


DELREC 1 


f 
1 


1 INDEXED, 
[ DIRECT, 1 
1 BUFFERED or 
\ UNBUFFERED 


VISAM 


IHEWITE 
1 (for format- 

IIEIITM 
* (for format- 




READ 


READ 1 




WRITE 


WRITE 1 




REWRITE 


WRITE 1 
1 




DELETE 


DELREC 


f 



52 



&PPEWDIX A; SECOMDABY STORIGE LIBEL FOBMAf 



Tiae Sharinf uses several groups of 
labels to ideatiff direct access and aag- 
Betic tape voliuies, and the data sets they 
c^>iitai]i, on secondary storage. The labels ^ 
used to locate the data sets, are identi- 
fied and verified by the label processing 
routines • 



segnence^ and is used for the allocation of 
the pages on the voluae. This field indi- 
cates whether the page is free and availa- 
ble for writing^ in current nse as a data- 
set page^ in use as a DSCB page, or 
unavailable. 



The use of standard labels enables the 
systea to identify volumes and ensurci that 
the correct volume is being used and that 
no current information is inadvertently 
destroyed. 



DIRECT ACCESS VOLUMES 



Direirt access volumes play a major role in 
TSS; they are used to store 

• Privileged service routines 

• The system catalog 

• The system library 

In addition, all public storage resides 
on direct access volumes. All data sets in 
public storage are organized as virtual 
access method (VAH) data sets. A direcrt 
access volume used for private data sets 
may contain all ?A« type or all physical 
seguential type date sets but not both 
types on one volume. 

f AH Data Sets 

iith the exception of tracks and 1 on 
cylinder 1 C^hich are reserved for system- 
generated volume information) , each VAH- 
formatted direct access volume is arranged 
into a succession of contiguous pages, each 
4096 bytes long. The first accessible page 
of the volume (which starts on byte 1, 
track 2, cylinder 1J is referred to as rel- 
ative page 0, and all other pages are num- 
bered consecutively. Other pages need not 
begin on track boundaries. Locations in a 
volume are referenced by relative page num- 
ber rather than by cylinder and track 
numbers • 



The standard volu 
cylinder 0, track 1, 
the page assignment 
one page long for vo 
pages for type 2314, 
3330, twelve pages f 
teen pages for type 
ment table contains 
each page in the vol 



me label, resident on 

contains a pointer to 
table (PAT) which is 
lumes of type 2311, two 

six pages for type 
or type 333B, and six- 
3350. The page assign- 
a one-byte field for 
ume, arranged in 



A data set page contains part of a data 
set. A data set control block (DSCB) of 
Pormat-E is associated with each data set. 
Each DSCB is 256 bytes in extent with a 
4i|-byte key containing the data set name. 
DSCBs reside on DSCB pages, 16 DSCBs to a 
page. They are not necessarily on the same 
volume as the data sets (or individual 
pages of the data sets) to which they 
refer. The 212-byte data portion of the 
DSCB contains the description of the data 
set and its location in storage, by volume 
and page numbers. If the DSCB is not long 
enough to contain the list of all page num- 
bers, the additional information is con- 
tained in one or more type-P DSCBs. 

When a data set is created, space is 
allocated for its data information and for 
the associated DSCB. A data set descriptor 
(DSD) is placed in the user^s catalog entry 
and gives the location of the format-B DSCB 
which in turn gives the location of the 
data set's data pages. 

VAl data sets on public storage are 
always mounted, but VAH-formatted private 
volumes must be mounted before the data can 
be accessed. Accordingly, the DSD for a 
data set on a private volume must also con- 
tain a pointer to the volume on which the 
data set resides, if it resides on one vol- 
ume, and to the volume on which the E- 
format DSCB resides, if the data set 
extends over more than one volume. 

The DSCBs contain pointers to the public 
volume table (PVT) which is maintained by 
the system in shared virtual storage. 
Volumes are referenced by relative volume 
numbers which the public volume table 
translates into symbolic volume addresses. 



Standard Volume Label (Pigure 12) ; The 
standard volume label resides on cylinder 
0, track 1 of the volume. The fields in 
the label are the same as those in the mag- 
netic tape volume label, described in table 
4, with these exceptions: 



PAT page 

pointer 



Contains the relative 
page number of the be- 
ginning of the PAT. 
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Device type 



Contains the device 
tjpe: 2311^ 2314, 
3330, 333B, or 3350. 



scribed in Figure 12, will be prefixed by a 
key of characters "YOLI" and the fields 
will be displaced by 4 bytes. 



▼oliiae status 
indicator 



Public voluBe 
number 



fll format 
indicator 



Indicates the status of 
the volume: 
•00 ■ = private volume 
•20» = public volume 

Contains the relative 
volume number of this 
volume within a set of 
public volumes. 

Indicates ?1M format: 
■V2» = VIM2 format 



Hoter System programmers using the Time 
Sharing Support System (TSSS) must expect 
an 84 byte voluMe label; the label, as de- 



Format-E DSCB (Figure 131 : This format is 
common to all VIH data sets. The format-E 
BSCB is the data set label; it corresponds 
to a tape header label, Ilso, it describes 
up to 38 pages of the data set. The format 
of the external page entries is described 
in Figure 14. 

Format~F DSCB fFigure 15) : This format is 
used to describe additional pages of a VAM 
data set, if there are more than can be de- 
scribed in the format-E DSCB. If addition- 
al space is needed, this DSCB will point to 
another foraat-F DSCB. The format of the 
external page entries is described in 
Figure 14 « 



VOL 
(label 

Identifier) 


1 
(volume 

label 
number) 


Volume 

serial 
number 


Volume 
security 


PAT 

page 
pointer 


Device 
type 


Volume 

status 

indicator 


Public 
volume 
number 


Reserved 

(currently 

blank) 


Owner name- 

and-address 

code 


VAM 
Format 

indicator 


Reserved 

(currently 
blank) 


1-3 


4 


5-10 


n 


12-13 


14-17 


18 


19-20 


21-41 


42-51 


52-53 


54-80 



Figure 12. Standard folume Label (VIl only) 



Data 

set 
name 


System 
code 


Pad 

for 

index 

sequential 


No. of bytes 

used in last 
data page 


Record 
format 


Spare 


Data 
set 

organi- 
zation 


(12 bits unused) 
Record length 
(20 bits) 


Spare 


Key 
length 


Key 
location 


Secondary 
allocation 


No. of 

data 

pages 


No. of 

directory 

pages 


No. of 

overflow 

pages 


No. of 
private 

vols 




1-44 


45-57 


58 


59-60 


61 


62 


63-64 


65-68 


69 


70 




73-76 


77-78 


79-80 


81 


82 



Total no. of 
pages assigned 
(Data set size 
at CLOSE) 



83-84 



Spare 



85 



Refer- 
ence 
date 



86-88 



Change 
date 



89-91 



Spare 



92-96 



-\^ 



-\^ 



List of volumes for private data set 
(each 6byte5^ variable length) 



I External page 
' entries^ each 

' 4 bytes long 

External page entries (for public vols) (on full -word 
(each 4 bytes long) boundaries) 



97-248 



41- 



Pointer 
to next 
DSCB if 
chained 



249-252 



DSC^ 
type 



253 



DSCB 
iD 



Check 
sum 



Figure 13. Format -1 DSCB 



15 16 



31 





W//. 






< 


^ 


Relative 

volume 


External 

page 






number 


number 


(2) 


m 


(12 bits) 


(16 bits) 



^ Assignment flag: 

00 if page is assigned and in use 
10 if page is assigned and unused 

Figure 11. External Page Entry 



^ . ^^ 

List of volumes for private data set 
(each 6 bytes ^ variable length) cfd from 
Format-E DSCB if required 



Externa! page entries each 

4 bytes long (on full-v/ord boundaries) 

SV- 



-^<r 



I External page 
' entries, each 
' 4 bytes long 

- (on full -word 
boundaries) 



1-248 



Pointer 
to next 
DSCB if 

chained 



249-252 



DSCB 



253 



DSCB 
ID 



254 



Check 
sum 



255-256 



Figure 15. For»at-F DSCB 



SH 



Fkvsical Sequential Pata Sets 

Back private storage volume tkat is for- 
matted for tke physical sequential access 
■etkod lias a volnae table of cxintents 
(▼TOC) tkat describes its contents; tke 
¥TOC contains all data set control blocks 
{BSCBs) for tke data sets contained on tkat 
volume* Tke ?TOC maj be located anjvkere 
on tke volnne, starting on a track bonnda- 
rj • It maf varf in size, but always kas an 
integral number of tracks. Tke starting 
address of tke ¥TOC is recorded in tke 
standard volmme label (refer to Figure 16> . 

Tke standard volume label resides on 
cylinder 0, track 0, of tke volume. Wken 
tke volume enters tke system, tke standard 
volume label and tke VTOC are created. Ill 
space on tke volume (except tke space occu- 
pied by tke volume label and VTOC) is tken 
available for allocation. 

Tke format of VTOC is specified wken tke 
volume enters tke system. Ill records kave 
a 4%""byte key and a 96-byte data portion, 
lack of tkese records becomes a DSCB, of 
varying type, and describes tke attributes 
and extents of a data set. 

lack DSCB contains tke name, descrip- 
tion, and location on tke volume of its as- 
sociated data set. It is created by tke 
system wken tke data set is stored on tke 
volume. Tke DSCB serves as tke data set's 
label and contains information similar to 
magnetic-tape labels . 



Cylinde 




VTOC 



Blank Storage Area 
for Data Sets 



Tke BSCBs are entered into tke VTOC as 
tkey are created and are placed in tke 
first available space, starting witk tke 
VTOC-DSCB (a format-4 DSCB) . Ivailable 
DSCB plots are recognized by a key field of 
binary Os. Wken a data set is deleted, its 
DSCB is overwritten witk Os, making it a 
format-0 BSCB. Is available extents in- 
crease, more direct access device storage 
management (DIDSH) DSCBs are entered into 
tke first available slot. It any time, tke 
fTOC kas a mixture of formats-1, -3, -4, 
and -5 DSCBs, and ••koles" for format-0 
DSCBs. Tkese formats will be explained 
below. 

DSCBs in formats -3 and -5 will appear 
to kave a key lengtk of 44 bytes, but por- 
tions of tke key may actually contain data. 
Tke DSCBs are all assigned tke same format 
to provide tke flexibility to convert an 
available DSCB (format-0) to anotker type 
of DSCB, and back again, witkout tke neces- 
sity for ckanging tke format or modifying 
tke ckannel programs tkat act upon tkem. 

Standard Volume label CFiqure 17) : Ilways 
tke tkird record on cylinder 0, track 0, of 
tke volume; tkis label identifies tke vol- 
ume. Tke fields in tke label are tke same 
as tkose in tke magnetic tape volume label, 
described in Table 4, except for bytes 
12-21, wkick contain tke address of tke 
VTOC. 

Mote: System programmers using tke Time 
Skaring Support System (TSSS) must expect 
an 84 byte volume label; tke label as de- 
scribed in Figure 17, will be prefixed by a 
key of ckaracters »V0L1» and tke fields 
will be displaced by 4 bytes. 

Format-0 DSCB ; Tkis is tke standard format 

of a data record in tke fTOC tkat is not 
currently occupied by any otker format of 
DSCB. Tke key and data portions contain 

binary Os. 

Format-1 DSCB (Figure 18) ; Tkis format is 
common to all pkysical sequential data 

sets. It consists of a 44-byte key field 
and a 96-byte data field. Tke format-1 

DSCB is tke data set label for direct 
access volumes; it corresponds to a tape 

keader label. Ilso, it describes up to 
tkree sets of contiguous tracks or cylin- 
ders on wkick tke data set resides. 

Format-3 DSCB CFiqure 19) ; Tkis format is 
used to describe extra extents of a data 
set, if tkere are more than can be describ- 
ed in tke format-1 DSCB. If additional 

space is needed, tkis DSCB will point to 
anotker foraat-3 DSCB. 



Figure 16. Direct Iccess Labels for Pkys- 
ical Sequential Data Sets 



Format-4 DSCB {Figure 201 ; Tkis format is 
tke first DSCB in tke VTOC of pkysical 

sequential volumes. 
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VOL 

(label 

identifier) 



1-3 



1 
(volume 
label 

number) 



Volume 

serial 

number 



5-10 



Volume 
security 



11 



VTOC 
pointer 



12-21 



Reserved 

(currently 

blank) 



32-41 



Owner name- 

and-address 

code 



42-51 



Reserved 

(currently 

blank) 



52-80 



WlguTB 17. Standazrd Volume Label (Physical Sequential Data Sets on Direct Access) 



Data set 


Fl 


Data set 


Volume 


Creation 




Expiration 


Number of 


Not 


Spare 


System 


Reserved l 


name 


(hexa- 
decimal) 
format 
identifier 


serial 

number 


sequence 
number 


date 


date 


extents on 
volume 


used 




code 




1-44 


45 


46-51 


52-53 


54-56 


57-59 


60 


61 


62 


63-75 


76-82 \ 



K 


Data set 


Record 


Option 


Block 


Record 


Key 


Key 


Data set 


Original 


Secondary 


Last 




type 


format 


code 


length 


length 


length 


location 


indicator 


request 
for space 


allocation 


record \ 
pointer J 




83-84 


85 


86 


87-88 


89-90 


91 


92-93 


94 


95 


96-98 


99-103 1 





Spare 


Extent 


Extent 


Lower 


Upper 


Additional 


Additional 


Pointer 


( 




type 


sequence 


limit 


limit 


extents 


extents 


to next 






Indicator 


number 






(same as 

bytes 

106-115) 


(same as 

bytes 

106-115) 


DSCB 
record 


1 


104-105 


106 


107 


108-111 


112-115 


116-125 


126-135 


136-140 



Figure 18. Foraat-l DSCB 



03030303 


Extent (in key) — 


F3 


Additional extents; 


Pointer to next 


(hexadecimal) 


4 groups of 


(hexadecimal) 


9 groups of fields 


format -3 




fields simi lar to 


format identifier 


simi lar to bytes 


DSCB 




bytes 106-115 in 




106-115 in 






format- 1 DSCB 




format- 1 DSCB 




1-4 


5-44 


45 


46-135 


136-140 



Figure 19. For»at~3 DSCB 



56 



Key field 
(contains 
hexadecimal 
04s) 


F4 

(hexadecimal) 
format identifier 


Last active 
format- 1 
or format— A 
DSCB 


, 

Available 

DSCB 
records 


Next 
available 
alternate 
track 


Number of 

available 

alternate 

track 


VTOC 
Indicators 


J 

01 

(hexadecimal) 

number of / 


1-44 


45 


46-50 


51-52 


53-56 


57-58 


59 


60 I 


















\ 


Reserved 


Device 
constants 


Spare 


Gross 

available 

space 


Pointer to 
format— 6 
DSCB 


VTOC extent - 
same as bytes 
106-115 in 
format— 1 
DSCB 


Spare 




/ 


61-62 


63-76 


77-95 


96-100 


101-105 


106-115 


116-140 





Figure 20. Foraat-^ BSCB 



05050505 
(hexadecimal) 
Key 
identification 


Available extent 


Available 
extents (in 
key) — same 
form as 

bytes 5-9 


F5 

(hexodecimal) 
format 
identifier 


Available 
extents (same 
format as 
bytes 5-9) 


Pointer 
to next 
format— 5 
DSCB 


Relative 

track 

address 


Number 
of full 
cylinders 


Number 

of additional 

tracks 


1-4 


5-6 


7-8 


9 


10-44 


45 


46-135 


136-140 



Figure 21. Fornat-S DSCB 



For»at~5 DSCB (Figure 21) : fhis fomat is 
always the second VTOC-DSCB for a volime 
contaiBing physical sequential data sets. 
It describes available extents on the vol- 
ume. If additional extents are needed ^ 
this DSCB is chained to other format-S 
DSCBs. 



EIGWETIC flPS fOLUHES 



Single Data Set /Single folume ; The volume 
begins with a volume label. The data set 
begins with a data set header label, a user 
header label (optional) , and a tape mark. 
The entire content of the data set is next. 
The last data block is followed by a tape 
mark and an EOF trailer label group, which 
is followed by the two tape marks that are 
the last records on the volume. 



Hagnetic tapes may be unlabeled or have 
standard labels. The €X>ntrol program sup- 
plies routines for automatic positioning 
and volume switching of such volumes. 



Ill standard tape 
character records, w 
binary coded decimal 
(EBCDIC) on nine-tra 
binary coded decimal 
national Standard Q> 
terchange, ANSI X3.^ 
ferred to as ASCII) 
The tape label is re 
density as the data 
in the DDEF command. 



labels are 80- 
ritten in extended 

interchange code 
ck tape units, and in 

(BCD) or the American 
de for Information In- 
-1968 (hereafter re- 
on seven-track units, 
corded in the same 
on the tape, specified 



Standard Tape Organization 

The organizations of standard labels and 
data on magnetic tape, for the tape organi- 
zations below, are illustrated in Figure 
22. 



Single Data Set/Hulti Volume : This is a 
simple expansion of the preceding descrip- 
tion, where the amount of information re- 
quires more than one volume. Ill volumes, 
except the last, of the set will contain 
the same organization as for a single data 
set/single volume, except that the trailer 
will be of an EOV trailer label group- The 
last volume will have the same organiza- 
tion, except that the trailer group will be 
an EOF trailer label group, followed by two 
tape marks. 

Hulti-Data Set/Single Volume ; The volume 
begins with a volume label. Every data set 
will start with a data set header label, a 
user header label (optional) , and one tape 
mark. The data set follows. Every data 
set (except the last) will conclude with a 
tape mark, an EOF trailer label group, and 
another tape mark. The last data set is 
the same, except that the EOF trailer label 
group is followed by two tape marks. 
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1 . single data set/sing 


le volume 
























V 
O 
L 


H 
D 
R 


T 
M 


Data blocks 


T 
M 


E 

O 
F 


T 
M 


T 
M 


\ 


2. Single data set/multi-volume (Volume 1 of 2) 


V 

o 

L 


H 
D 
R 


T 

M 


First part of data set N 


T 
M 


E 

O 
V 


T 
M 




(Volume 2 of 2) 


V 

o 

L 


H 
D 
R 


T 
M 


Last part of data set N 


T 
M 


E 

O 
F 


T 
M 


T 

M 




3. Multi-data set/single volume 


V 
O 
L 


H 
D 
R 


T 
M 


Data set A 


T 

M 


E 
O 
F 


T 
M 


H 
D 

R 


T 

M 


Data set B 


T 
M 


E 

O 
F 


T 
M 


T 
M 




4. Multi-data set/multi-volume set (Volume 1 of 


3) 
















V 
O 
L 


H 
D 
R 


T 
M 


Data set A 


T 
M 


E 
O 

F 


T 
M 


H 
D 
R 


T 
M 


Data set B 


T 
M 


E 
O 
V 


T 
M 


I 


(Volume 2 of 3) 


V 
O 
L 


H 
D 
R 


T 
M 




< 


lontinuatlon of data set 


B 




T 

M 


E 
O 
V 


T 
M 




(Volume 3 of 3) 


V 
O 
L 


H 
D 
R 


T 

M 


Last part of 
data set B 


T 
M 


E 
O 
F 


T 

M 


H 
D 
R 


T 

M 


Data set C 


T 
M 


E 

O 
F 


T 
M 


T 
M 





Note: This is an example (Volumes 1 through 3, inclusive) of the successive recording of data sets on physical volumes to maximize tape use. 



Figure 22. Standard Label and Data Organization on Magnetic Tape 



gglti-Data Set/Molti VolttiBe ; This volii»e 
is similar to the previous one, except that 
the aaount of infornation requires nore 
than one voluae. These rules must be fol- 
loved in producing the additional Tolunes: 



Each volume, except the last, must 
conclude with a tape nark, an 107 
trailer label group, and a tape Bark. 

Each volume begins with a volume 
label. 

The initial data set header label on 
each volume, except the first, is a 
repetition of the last data set header 
label on the previous volume, with the 
exception of the volume sequence 
number • 



Volume Label 

The volume label identifies a volume and 
its owner, and is used to verify that the 
correct volume is mounted. It can also be 
used to prevent use of the volume by au- 
thorized programs. 

Tables 5 and 6 show the organization of 
standard tape labels and describe their 
fields. 

I tape using standard labels is identi- 
fied as such by the system when it reads 
the initial record, and determines that it 
is a volume label by finding that these 
criteria have been met: 

• Initial record consists of 8^ 
characters 
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• First fomr chairac-ters of tlie record are 
?0L1 

Tke system autoaaticallf cliecks the vol- 
uae label to ensure that it is in the prop- 
er format; if the format is correct, the 
sjstem checks the label information. 
ShonM the check indicate an error {toT ex- 
ample, the system finds that the wrong vol- 
ume has been mounted) , it issues a message 
to the operator* Similarly, messages are 
issued if errors are detected in other 
label and format checks. 



Data Set Header Label Group 

The data set header label group consists 
of HDB1 and HDE2. These labels are created 
by the system when the data is recorded. 
HDBl, as shown in Tables 7 and 8, contain 
system data and device -dependent informa- 
tion. HD12, shown in Tables 9 and 10, con- 
tain data set attributes. If there are no 
user header labels, HI)12 is followed by a 
tape mark. The grcmp can be used in 
forward— reading operations to: 

• Locate the data set 

• ferify reference to the data set 

• Provide information for the DCB. 



Pser Header Label Group 

I maximum of eight user header labels 
may follow the data set header label group. 
The labels are written by the system, as 
directed by the problem program that rec- 
ords the tape. The group is ended by a 
tape mark. 

When the tape is read, the user header 
label group is made available to the pro- 
blem program by the system; the format of a 

label is shown in Table 11 . 

Data Set Trailer Label Group 

The data set trailer label group con- 
sists of two labels that duplicate the data 
set header labels to facilitate backward 
reading of 'the tape. The format for the 
trailer labels is identical to the data set 
header labels, except for the fields shown 
in Table 12. These labels duplicate the 
data set header labels to facilitate back- 
ward reading of tape. Location and verifi- 
cation of the data sets can also be 
achieved with data set trailer labels. 

User Trailer Label Group 

k maximum of eight user trailer labels 
can, optionally, follow the data set trail- 
er label group. They are written exactly 



Table 5. EBCDIC Volume Label Format (Magnetic Tape) 



S " ■ " ■ ■T" " '1 "1 "'" " " " " —" 1 

1 Field 1 Position | I | 
1 lumber | (Bytes) | lame I Use I 


I 111-3 1 Volume label identifier I Contains ••VOL*^ to indicate record is | 

III 1 volume label I 


1 2 1 4 1 Volume label number | Contains "I" to indicate this is first | 
III 1 volume label | 


1 3 1 S-10 1 Volume serial number | Contains unique identification code, | 
III I assigned when volume entered system; it | 

III 1 can be copied on external surface of | 
1 1 I 1 reel for visual identification; field | 
III 1 normally numeric (000001-999999) , but | 

III 1 may contain any six alphameric | 
III 1 characters I 


1 4 1 11 1 lot used by TSS | Recorded as EBCDIC Os | 


1 5 f 12-21 1 leserved | Becorded as blanks | 


1 6 i 22-31 1 leserved for manufac- | Reserved for future use; must be blank | 

1 1 1 turers I | 


1 7 1 32-41 1 Reserved f leserved for future use; must be blank | 


1 8 1 42-51 1 Owner name-and-address | Contains unique identification of owner | 
1 1 1 code 1 of volume I 


1 9 1 52-80 1 Reserved f leserved for future use; must be blank | 

L-.-^ __.. ^ ...J.™.. _„,„ Jt . . „_ „_ ^.. .._ ,... IL.,- ..-„.. - „... „ „. «, ^ ,.. _,« , 1 
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the saae as the user header labels, except 
for the difference noted in Table 13. 

Oser trailer labels specify inforaation 
pertaining to the data sets on the volnae* 
These labels contain information that can 
not be put into the standard header labels 
or into the records themselves. 



A conmon use of these labels is to store 
control inforaation (for example, the nua- 
ber of records in the data set, or the num- 
ber of read-errors encountered in reading 
the data set) • 



Table 6. ASCII ?oluae Label Foraat (Magnetic Tape) 



J 1— — ^ .,. ^ - .,. .- — .— _ -^ 

1 Field 1 Position | I I 
1 luaber | (Bytes) | Maae \ Use | 


1 1 f 1-3 1 Voluae Label Identifier | Contains "?0L'» to indicate record is | 
lit 1 Tolune label 1 


1 2 1 4 1 ?oluae Label Muaber | Contains "I** to indicate this is first | 
III 1 Toluae label I 


1 3 1 5-10 1 Voluae Serial Wuaber | Contains six alphaaeric characters per- | 
III 1 aanently assigned by the owner to iden- | 
III 1 tify this voluae I 


1 4 1 11 1 foluae Accessibility | An alphaaeric character indicating I 
III 1 restrictions on access to the voluae. | 
III 1 A blank indicates unlimited access; any | 
III 1 other character indicates special han- | 
III 1 dling according to the agreeaent be- | 
1 1 1 1 tween interchange parties. I 


1 5 1 12-31 1 leserved for future | Must contain blanks I 
1 1 1 standardization f I 


1 6 1 32-37 I fieserved for future | Hust contain blanks I 
1 1 1 standardization | I 


1 7 1 38-51 1 Owner Identification | Contains unigue ID of owner of voluae | 


1 8 1 52-79 1 Reserved for future | Rust contain blanks I 
1 1 1 standardization I 1 


1 9 1 80 1 Label Standard Level | May contain a "1" or blank. One (1) | 
III 1 indicates voluae labels and data for- I 
III 1 aats confora to this standard. Blank I 
III 1 indicates labels and data formats re- | 
III 1 guire agreeaent of interchange parties. | 
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Table 7. EBCDIC Data Set Header-1 Label Foraat 

I 1 1 ^ 1 — 



t Field 1 Fosltloa r 1 1 
1 Wuaber | (Bjtes) | Vase | Use I 


I 1 1 1-3 1 Label iientifier | Contains "HDB" to indicate this is | 
1(1 1 header label | 


1 2 1 ft 1 Data set label nnaber | Contains ••I'* to indicate this is first | 
1 1 i 1 data set header label | 


1 3 1 5-21 1 Data set Identifier | Identifies data set; aay contain only | 
III 1 alphameric characters I 


1 ft 1 22-27 1 Data set serial number I Contains same identification code as in | 
III 1 field #3 of the initial volume label of | 
III 1 the volume on which the data set | 
III 1 resides or of the first volume of a | 
III I aultidata set aggregate I 


1 5 1 28-31 I Volume sequence number | Indicates volume on which data set is | 
III 1 recorded, relative to volume on which | 
III 1 data set or aggregate begins | 


1 6 1 32-35 1 Data set sequence | Indicates position of data set relative | 
1 1 1 number I to first data set in aggregate; range | 
III 1 from 0001 to 9999 | 


f 7 1 36-39 1 Generation number | Indicates generation number (0001-9999) | 
III 1 of data set | 


1 8 1 ftO-ftI 1 Version number of | Indicates version of generation of data | 
I 1 1 generation I set | 


1 9 1 ft2-ft7 1 Creation date I Indicates year and day data set was | 
III 1 created; recorded as bITDDD (TY is | 
III 1 00-99 and DDD is 001-366) I 


1 10 1 ft 8 -5 3 1 Expiration date | Indicates first day tape may be over- | 
1 1 1 1 written; recorded as bTIDDD | 


1 11 1 5ft 1 Hot used by TSS | Contains EBCDIC Os | 


1 12 1 55-60 1 Unused | Contains Os | 


1 13 1 61-73 1 System code | Contains unique identification of pro- | 
III 1 gramming system | 


1 1ft 1 7ft-80 1 leserved f Beserved for future use; must be blank | 

1 1 1 1 __ , 
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Table 8. ASCII Tape Data Set Header-1 Label Foraat 



f 1' ' 1 ' "1 "■" - — ■ - ■ 1 

1 Field I Position | I I 
1 HuBber | (Bytes) | Haae ) Ose I 


1 1 I 1-3 1 Label identifier | Contains "HDR»® to indicate this is | 
III 1 header label I 


I 2 1 ^ 1 Data set label nnaber | Contains »»1" to indicate this is first | 
ill 1 data set header label ! 


1 3 1 5-21 i Data set identifier f Identifies data set; maj .antain only | 
III 1 alphameric characters f 


1 4 1 22-27 1 Data set serial nnnber | Contains same identification code as in | 
III 1 field #3 of the initial volume label of | 
III 1 the volume on which the data set I 
III 1 resides or of the first volume of a I 
III 1 mnltidata set aggregate I 


1 5 1 28-31 1 ¥olmme sequence number | Indicates volume on which data set is | 
III 1 recorded, relative to volume on which | 
III 1 data set or aggregate begins I 


1 6 1 32-35 1 Data set seguence | Indicates position of data set relative f 
1 1 1 number I to first data set in aggregate; range | 
III 1 from 0001 to 9999 I 


1 7 I 36-39 1 Generation number | Indicates generation number (0001-9999) | 
1 1 1 (optional) 1 of data set I 


1 8 1 40-41 1 Version number of | Indicates version of generation of data | 
I I 1 generation (optional) | set | 


I 9 1 42-47 1 Creation date | Indicates year and day data set was | 
III 1 created; recorded as bYIDDD (YY is I 
III 1 00-99 and DDD is 001-366) I 


1 10 1 48-53 1 Expiration date I Indicates first day tape may be over- | 
III 1 written; recorded as bYYDDD I 


I 11 1 54 1 Data set accessibility | Contains an alphameric indicating | 
III 1 access restrictions to this data set. | 

II 1 1 1 blank indicates unlimited access; any | 

III 1 other character indicates special han- | 
III 1 dling according to agreement between | 
III 1 interchange parties. I 


1 12 i 55-60 I Block count | Bust contain zeros I 


1 13 I 61-73 I System code I Contains unique identification of pro- | 
1 1 1 (optional) I gramming system | 


1 14 I 74-80 1 leserved I Reserved for future use; must be blank | 
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Table 9. EBCDIC Data Set Header-2 Label Format 

I 1 1 ^ 



T- 



1 Field 1 Position | 1 1 
1 laaber | (Bjtes) | lane | Use | 


1 1 1 1-3 1 Label identifier | Contains ••HDR" to indicate header label | 


1 2 1 4 1 Data set label nnaber f Contains »2'» to indicate second data | 
III 1 set header label | 


I 3 I 5 1 lecord format f Indicates format of records: I 

II 1 1 F - Fixed length I 
II 1 1 V - Variable length I 
II 1 1 U - Undefined | 


1 4 1 6-10 1 Block length I Indicates length of block; interpreta- | 
III 1 tion of field depends on format speci- | 
III 1 fied in field #3: | 
III f Format F - Length of a physical block | 
1 f 1 1 Format V - Haximnm length of a block | 
III 1 Format U - Maxianm length of a block | 


1 5 1 11-15 1 Logical record length | Indicates length of logical record; in- | 
III 1 terpretation depends on record format | 
III 1 specified in field #3: I 
III 1 Format F - Length of a logical record | 
III 1 Format V — Haximnm logical record | 
III 1 length I 
III 1 Format U — This field contains Os | 


1 6 1 16 1 Density 1 Indicates tape density: 1 
III 1 Density fbits/inch> 1 
III f Hodel 2400 1 
III I DIH Value 7-track 9-track | 

III 1 200 1 

III f 1 556 — I 
III 1 2 800 800 1 

III 13 1600 1 

ill 1 4 6250 I 


I 7 1 17 1 Data set position | Indicates whether volume switched pre- | 
III 1 viously for data set; volnme switched^ f 

II 1 1 1 is written; if not, is written; | 

III 1 when tape is read backwards, this in- | 
III 1 formation indicates when volnme switch | 
III f is required I 


1 8 1 18-34 1 Hot used by TSS | lust be blank I 


1 9 1 35-36 1 Tape recording | Indicates, for 7-track tape, technique | 
1 1 1 technique f in creating this data set I 


III 1 BCD Code Meaning I 


III 1 Cb Data conversion fea- | 
III 1 ture used I 


III 1 lb Even parity used | 


III 1 Tb BCD to EBCDIC trans- | 
III 1 lation required | 


III 1 ET Even parity used; | 
III 1 BCD to EBCDIC trans- I 
III I lation required | 


III I bb Odd parity, no trans- | 
ill 1 lation required; or | 
III 1 this is 9-track tape | 
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Table 9. EBCDIC Data Set Header-2 Label Format (continued) 



1 "1 1 • "f -■' ■ •— — ■■- - ■" - — — 1 

I 10 1 37 1 Control character | Indicates type of control character | 
III 1 (first data character of each record) | 
III 1 used to control printer-spacing and | 
III 1 punch -selection: I 

II 1 1 I - American national Standard POITB&H I 

III 1 control character I 

II 1 IE- Machine-code control character | 
1 1 1 f b - Ho control character used | 

III 1 > 


III 1 1 
1 t1 1 38-80 1 leserved | Hust be blank I 



Table 10. 



ASCII Data Set Header-2 Label For mat 

1 r- 



1 Field 1 Position | | | 
1 lumber | (Bytes) | lame I Use I 


1 1 1 1-3 1 Label identifier I Contains ••HDE" to indicate header label | 


1 2 I * 1 Data set label number | Contains ••2" to indicate second data | 
III 1 set header label | 


I 3 I 5 1 Record Format I Indicates format of records: I 

II 1 IF- Fixed length | 

II 1 1 D - ?ariable length (specified in | 

III I decimal) I 
II 1 I U - Undefined | 


i 4 1 6-10 1 Block length | Contains five numeric characters speci- | 
III 1 fying the maximum number of characters | 
III 1 per block | 


1 5 I 11-15 1 Logical record length I Indicates length of logical record; in- I 
III 1 terpretation depends on record format | 
ill I specified in field #3: I 
III 1 Format F - Length of logical record | 
III 1 Format D - Maximum logical record | 
III 1 length (count fields incl.) | 
III 1 Format U - Contain zeros f 


1 6 1 16-50 1 leserved for operating | Contains alphameric characters reserved | 
1 1 1 systems I for operating systems use I 


1 7 1 51-52 1 Buffer offset (optional) | Contains two numeric characters speci- | 
III 1 fying the length, in characters, of any | 
III 1 additional field inserted before a data | 
III 1 block, e.g., block length | 


I 8 1 53-80 1 leserved for future | Must contain blanks I 
1 1 1 standardization I t 
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table 11. User Header Label Format 



■ - 'P ■ " ■» ■ "i ■ 1 

1 Field 1 Position | I | 

1 lanber | (Bytes) | lane | Use | 
III 1 1 


I 1 1 1-3 1 Label identifier | Characters "uhl" indicate tkis is nser r 
III 1 header label | 


I 2 1 i> 1 Label number I Identifies relative position (1-8) of | 
III 1 label within label group I 


1 3 1 5-80 1 User specified | Used to specify information pertaining | 
III 1 to data set or sets on volume | 

1 1 1 1 .1 



Table 12, 



0ata Set Trailer Label Format 



r ' ■ ■ 1 

1 Format of trailer labels is identical to data set header labels (Tables 5 and 6) , ex- | 
1 cept for these fields: | 


1 Field I Position | I | 
1 Number | (Bytes) | lame I Use | 


1 1 1 1-3 1 Label identificjr f Characters "EO?" indicate end of vol- | 
III 1 ume; ••EOF" indicates end of data set? | 
III 1 field indicates this is data set trail- | 
III 1 er label | 


1 2 1 4 1 Label number I Indicates label is first (1) or second | 
III 1 (2) data set trailer label | 


1 12 1 55-60 1 Block count | Indicates number of blocks in data set | 
III 1 on current volume of multi-volume data | 
III 1 set,, with range of 000000 to 999999; | 
1 1 1 1 indicates number of blocks from last | 
III 1 label of label header group to first | 
III 1 label of trailer label group r exclusive | 
III 1 of tape marks | 



Table 13. User Trailer Label Format 



i "1 1 1 - - - - "- — ■ -- — 1 

1 Field 1 Position | I | 
1 number | (Bytes) | lame | Use | 


ill 1 f 

1 1 1 1-3 I Label identifier | Characters «UTL»» indicate this is user | 
III 1 trailer label | 
III i * 


111 1 1 
1 2 I 4 1 Label number I Identifies relative position (1-8) of | 
III 1 label within label group | 
III 1 I 


III 1 "1 

1 3 1 5-80 1 User specified | Used to specify information pertaining | 
III 1 to data sets on the volume | 

1 1 1 1 _.._ „. 1 
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APPEWDIX B; DATA SET BBFIWIHG FOB COHBAHPS &HD L&IIGO&GB PROCESSOIS 



DATA SET DEFIMITIOM RU LES FOB LAHgUAGE 
PROCSSSIMG 

Table 14 provides information relating 
to the organization of and DDEF require- 
■ents for data sets involved in assembly, 
compilation and linkage-editing. 



DATA SET DEFIBITIOy ROLES FOR TSS COBHAMDS 

Table 15 provides information relating 
to the struirture of and DDEF requirements 
for data sets processed by TSS commands. 



Table 11. Data Set Definition Rules for Language Processing 



1 1 
1 Command 


r '" — ■ — ■ — • •■ • ' - - -^ 

Related Data Sets 
1 


1 DSORG 


Data Set Definition Rules f 


|ASe 

I (ASSEMBLES) 


f 
Source program data set. 

1 
1 


! VI 1 
ILine data set 


Source program data sets: If | 

supplied as part of SYSIN data) 

Iset, these data sets do not f 

require any further defini— | 

tion. If supplied as pre- j 

stored data sets, they must be| 

[cataloged, lo DDEF required | 

prior to an ASl, COBOL, FTI, I 

»FTHH, HASH, PLI or PLIOPT | 

command. | 




i 
Object module. 

( 

1 


1 ¥S 

1 (¥P member) 




Listing data set. 
r 


[ ¥1 

[List data set 


1 COBOL 
1 (COBOL) 


Source program data set. 

1 


I VI 

1 vs 




I 
Object module. 

1 
1 


[ vs 

f (VP member) 






Listing data set. 
1 


! VI 

[List data set 






I 

Load data set (created by 
program product COBOL 
not yet converted to 
object module) . 

1 


the 


1 VS 






1 

Source statements for inser- 
tion by preprocessor (Mote 1) . 

1 


1 VI 

' (VP member) 




IFTM 

f (FORTRAl) 


Source program data set. 


1 VI 

fLine data set 


Object module: The module is | 
placed in the library at the | 
top of the program library I 
list. If a job library is to | 
receive the object module, a | 
DDEF command must define the | 
library. | 




Object module. 


[ VS 

(VP member) \ 




Listing data set. 


VI 
List data set 


1 FTIH 

I (FOITRAW H 1 

lEXTElDBD) 1 


Source program data set. 


VI 
VS 






Object module. | 

1 


VS 1 
(VP member) 






Listing data set. 

1 


VI 1 
List data set! 






Load data set (created by 
program product FORTRA¥ H 
not yet converted to 
object module) . 


the 
1 

1 
1 


VS 1 


Listing: lo DDEF command | 
required | 



lote 1: DDEF command is required if VP data set is not USSRLIB. 
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fable 11. Data Set Definition Inles for Language Processing (Continued) 

^ 1 , 



■TT 



1 Cosaand | lelated Data Sets | DSOIG | Data Set Definition Rules | 


|H1SH 1 Source program data set*. | ¥1 fSane rules as for ASH. 1 
1 (ASSHBLl H) 1 r ITS 1 1 


1 1 Object module. ( VS | I 
1 1 f (ITP member) | 1 


1 (Listing data set. | ¥1 I I 
1 t (List data set) I 


1 {Load data set (created by tbe | ¥S | I 
1 1 program product ASSEHBLEB H I | I 
1 I not jet converted to | | I 
1 1 object module) .11 1 


JfLI (Source program data set,. | ¥1 (Same rules as for ISM* I 
1 (PL/I (P) ) r 1 1»ine data set I I 


1 [Object module. t ¥S | | 
1 I f (¥P member) | I 


1 (Listing data set. I ¥S | I 
1 1 (List data setf | 


1 ILoad diata set (an object mod- | ¥S |lo DDIF command required. | 
1 |ule tbat has been crreated bj I 1 1 
1 Itbe TSS PL/I (F) compilcjr but | I I 
1 |not converted from card--image | I I 
t fform) . II 1 


1 (Source statements for inser- | ¥1 (DDEP command required if ¥P | 
1 (tion by preprocessor. | (¥P member) (data set is not USERLIB. ( 


1 (Storage for: ( ¥1 (DDEF command required if data | 
( 1 (Line data set (set is not the MIC. name (0) | 
( 1 1. Translated source state- | (data set created automatically! 
( ( ments when 48-characrker | (by the preprocessor. | 
( 1 set not used. ( I | 

1 ( 2. Source statements gener- I ( ( 
( 1 ated by the preprocessor. ( ( | 


(PLIOPT (Source program data set. ( ¥1 (Same rules as for ASM. ( 
( (PL/I ( ( ¥S ( 1 
(OPTIIIZIIG ( ( ( I 
(COMPILER) ( (1 1 


[ (Object module. ( ¥S I ( 
1 1 1 (¥P member) j | 


1 (Listing data set. ( ¥1 | | 
1 ( (List data set( ( 


( (Load data set (created by the ( ¥S ( ( 
1 (program product PL/I ( ( ( 
( I OPTIMIZING COMPILER not yet ( | | 
( (converted to object module) . ( ( ( 


( (Source statements for inser- ( ¥1 (DDEF command required if ¥P | 
( (tion by preprocessor. ( (¥P member) (data set is not USERLIB. | 
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Table 14. Bata Set Definition Enles for Language Processing (Continued) 



Cob Band 



Belated Data Sets 



DSOBG I Data Set Definition Eules 

1 



LBK 
(IIIKIGE 

EDITOE) 



Source program data set- 



VI (Same rules as for ASM, PTM, 
Line data set J and PL/I (F) . 



Libraries that are to supply 
object modules. 



H 



VP 



Library to receive output ob- 
ject module. 



■4 

I Each library referred to by 
IIUCLODB statements except 
IDSIHLIB and each job library 
fused by automatic call must be 
I defined by a DDBE command. 

"4 



¥P 



I If library at top of program 
I library list is to receive 
I output object module r no addi- 
Itional DDEF in this task. 
I If another library is to re- 
Iceive output , it must be de- 
I fined by previous DDEF command 
land be specified by its ddname 
I to linkage editor program. 



Listing data set. 



VI 
List data 



set I 



-I 

fllo DDEF command required. 



^ 



Table 15. Data Set Definition Requirements for Commands 



r 1 ■ ' '1 ' -1 T 

I Command | Belated Data Sets | DSOBG | Data Set Definition I 

II II 1 


II II 1 
fBACK INew SYSIH data set that is to| VS, VI |Ke¥ SYSIH data set must be | 
f 1 control completion of this \ (cataloged or defined by pre- | 
I Itask in nonconversational j |vious DDEF command in I 
1 Imode. I 1 conversational portion of thisj 

I r 1 Itask. 1 

II II 1 


If II 1 
IBDILTIM 1 Object module in user^s pro- | VP J Data set must be defined in | 
1 Igram library hierarchy. | (current task, or must be | 

I 1 1 (cataloged. ( 

II II i 


11 II 1 
(CATALOG (Data set to be cataloged. ( PS (Data set to be cataloged must ( 
1 i 1 (be defined by previous DDEF | 
1 1 1 (command in this task, unless | 
1 ( ( (UPDATE option specified. ( 


r 1 II 1 
(CDD (Data set containing only DDEF| VI (Data set must be cataloged, ( 
f (commands. f (defined in current task. | 
t 1 II 1 


II If 1 
|CDS (Original data set: Existing ( VS, VI (Data set to be copied must be ( 
1 (data set or one or more mem- ( (cataloged or defined by pre- ( 
1 (bars of partitioned data set. J (vious DDEF command in this ( 
1 t 1 Itask. ( 


11 If 1 
1 IMew copy: Can be data set, | VS, VI (Provided by system. I 
1 (one member of partitioned I ( ( 
1 (data set, or entire parti- | [ ( 
i Itioned data set. 1 I 1 
■ 1 II 1 


II If I 
1 CLOSE IData set to be closed. | any |Data set to be closed must be ( 

I j ( (defined by previous DDEF com- ( 

II II mand in this task . I 
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Table 15. Data Set DefinitioE leqiiire»ents for Commands (continued) 

I 1 ^ 1 ^ 1 



J Command | Related Data Sets 1 DSOHG | Data Set Definition | 
II II * 


11 II '1 
fDITA* IData set to be entered. | VS, VI tllo DDIF command is required if | 
1 1 1 Ithe data set is to reside on | 
1 1 ( f public storage; data follows | 

I 1 f Ithis command in input stream. | 

II 1 |If the data set is to reside- | 

II 1 Ion private storage a DDBP musti 

II I |be issued before the command. | 
It 1 1 1 


1 ' f 1 1 ■ " - — 1 

IDlFIUll! lOser profile data set I ?P I Provided by system. | 

I ISYSPRX in USllLIB. | | | 

II ft > 


1 1 If 1 

IDILBTB IData set vkose name is to be | Iny jHo DDEF command required for f 
1 [removed from catalog. | Ithis command. I 


r 1 1 1 f 
|DSS? IData sets whose status is de-| Iny |lach data set whose status is | 
1 1 sired* I I to be presented must be cata-- | 
1 1 1 lloged; no DDE? command re- | 

I f 1 1 quired for this command. | 

II 11 1 


II III 

IDOHP IData set to be printed as a | VI |DDBF command whose ddname is | 
1 [result of program control (List data setlPCSOUT must be defined prior I 
1 1 command DUHP. I I to execution of DUHP command. | 
If II f 


1 I If 1 
IEDIT2 [Data set to be processed by | VI |Data set must be cataloged ^ orf 

I |the Text Editor. | [defined in current task. Thisj 

II 1 lis done automatically. I 
II II 1 


1 1 II 1 
|EMD^ IData set being processed by | VI |Ho DDEF command required for | 
1 [the Text Editor, or indicates | [this command. 1 

I IPEOCDEF command completion. t I I 

II 11 1 


1 1 If 1 

[ElASE [Data set to be erased. | Any |Data set to be erased must be | 
1 1 1 (cataloged, or DDEFed. | 

1 i II 1 


|EV? [Private data sets whose names |VS, VI, ?P |lo DDEF command required for | 

I tare to be entered in catalog. | {this command. 1 

II t 1 t 


lEXECUTE [SYSIN data set for nonconver-| VS, VI [Data set must be cataloged; nof 
I jsational task set up by this | JDDBF command required by this | 
1 [command. I Icommand. I 


1' 1 f 1 1 

[LIME? ILine data set containing f VI |Line data set must be | 
1 1 lines to be presented. |List or line [cataloged or defined by pre- | 
1 1 1 data set jvious DDEF command in this [ 
1 1 1 [task. 1 
t t II 1 


1 1 1 1 1 
[LOAD [Object module to be loaded. | VP [Object module to be loaded is [ 
1 1 1 (VS member) [identified by external name | 
1 1 1 [specified in this command; it [ 
1 I f [must be in a library in the | 

I 1 1 [current program library list. | 

II If 1 


1 MODIFY IData set to be changed. [ VI [Data set must be cataloged or | 
I 1 I [defined by previous DDEF com- t 
1 1 1 [mand in this task. f 


r " ■ ■ 1 " — " — '" f' ' 1 1 

[PC? (Data set whose status is re- | Iny [Each data set whose status is | 
1 [quired. I I to be presented must be cata- I 
1 I 1 [loged; no DDEF command re- | 
1 1 1 [quired for this command. ( 


f ' 1 i 1 i 

1 PERMIT [Data sets for which sharing f Any (Data sets for which sharing is| 
i [is permitted I [permitted must bo cataloged; | 
I I 1 [no DDEF command required for I 
1 1 1 Ithis command. 1 
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Table 15. Data Set Definition legmireaeats for Coaaands (coatinaed) 



f^ 


1"- - 1 " -1 1 "^ -I 

1 Coaaand | Belated Data Sets | DSOBG | Data Set Definition I 
> > II 1 


|POD? |?irtual partitioned data set I VP | Virtual partitioned data set f 
1 (for which inforaation about | laust be cataloged, or defined | 
1 |its aeabers is given. I I by previous DDEF command in f 
1 1 1 Ithis taslc. 1 

1 i If 1 


1 " ■ f ■ 1 1 1 

IPEIST [Data set to be printed. IPS, VS, VI |Data set aust be cataloged or | 
1 1 i I defined by previous DDEF coa- f 
1 1 1 laand in this task. A previous! 
1 1 1 IDDIF reguired for unlabeled | 
1 1 1 (tapes. 1 
• > II 1 


f— '" ■ " 1 II ■! 

JPROCDEF IData set which consists of J VI [Provided by systea. | 
1 [other coaaands, to becoae a | | ( 

I [user-written procedure. | I I 

II II 1 


11 If I 
[PROFILE [User profile data set in | VP [Provided by systea. | 
1 [OSEILIB, session profile in | | I 
I [task virtual aeaory. f 1 [ 
> > II 1 


t 1 II 1 
(PtJHCH [Data set to be punched on | VS, VI [Data set aust be cataloged or | 
1 [cards. I [be defined by previous DDEF [ 
[ 1 1 [comaand in this task- I 
It 11 1 


1 1 f 1 1 

1 REGION 2 [Data set to be processed by | VI [Data set must be cataloged, or| 
1 [the Text Editor. ( [defined in current task. | 
• 1 II 1 


1 1 f 1 1 
[HSLEIlSE [Data set whose definition is f Any [Data set whose definition is [ 

I [to be released. I [to be released aust be defined | 

II 1 [in previous DDEF coaaand in | 
1 1 1 [this task. [ 
■ 1 II 1 


II If 1 
|RBT [VAH data set whose data set |VS, VI, VP [Data set aust be cataloged. | 

I [descriptor is to be changed. [ I | 

II If 1 


1 r f . . . . i i . i| , . i 1 

[SHARE [Data sets for which sharing | Any [Data sets for which sharing is| 

1 [is reguested. | [reguested aust be cataloged by[ 

1 1 1 ftheir owner; no DDEF coaaand | 

1 1 1 Ireguired by this comaand. | 
t t It • 


ISYHOMYl [User profile data set in | VP [Data sets aust be defined in | 
1 [USERLIB, session profile in 1 [current task. I 

I [task virtual storage. 1 1 1 

II II 1 


11 f I 1 

|TV [Physical seguential data set | PS |Data set (input) aust be cata-| 
1 1 (froB a VT operation) to be i jloged or defined in current | 

I [written on a VAH volume. | [task- I 

II II t 


II 1 1 — f 

[VT |VA1 data set to be copied to |VS, VI, VP [Data set (input) aust be cata-| 
1 [aagnetic tape as a physical I floged or defined in current | 
1 [seguential data set. [ [task. I 


1 f 1 ■"'1' ' '■ ■- — 1 

|VV [VAM data set to be copied |VS, VI, VP [Data set (input) aust be cata-| 
1 [into direct access storage. | [loged or defined in current | 

1 1 1 [task. 1 
1 1 t 1 1 


1 f 1 f — - i 

|1T IData set to be recorded on | VS, VI [Data set must be cataloged or f 
1 [magnetic tape in print | [defined by previous DDEF com- | 
1 1 format. I [mand in this task. j 
1 ^ , II 1 


[ »If the DATA comaand was used to create the data set within the current task, then the[ 
1 data set is defined as if a DDEF command had been issued by the user directly- If the I 
1 data set is also VAM organized and resides in public storage, it is autoaatically | 
1 cataloged . | 

I^These are the basic directive commands of the Text Editor- See Coaaand System User's 1 
[ Guide for details concernina the data aanipulation commands of this facility. 1 
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APFEHDIX C; TSS RECORD FORMATS 



TSS logical records Maj be in one of 
three formats: fixed-length (format-FJ ^ 
variable-length (fornat-? and fomat-D) , or 
undefined (f oraat-U) . 

fhe prime consideration in the selection 
of a record format is the nature of the 
data set itself* The user knows the type 
of input his program will receive and the 
type of output it will produce. Selection 
of a recjord format is based on this knowl- 
edge ^ as well as an understanding of the 
type of input/output devices that are to 
handle the data set^ and of the access 
method used to read and write the data set. 

In the case of ASCII tape records, the 
user should be aware that TSS translates 
the records to EBCDIC on input to process 
them and translates them back to ASCII form 
for output. Since some ASCII records begin 
with a crontrol information field that is 
foreign to TSS, the size of this field 
(buffer offset) must be identified as part 
of the record format. 

The record format of a data set is 
placed into the data control block accord- 
ing to specifications in the DCB macro in- 
struction, the DDEF command, or the DDBF 
macro instruction. 



When unblocked, the logical record and 
the block control information constitute 
the block. The block control information 
(four bytes) must be included in the record 
length. 

In blocked format-?, the block length, 
LLbb, is prefixed to each block, LI repre- 
sents the block length, and bb represents 
two characters reserved for system use. 
This four-byte block length field must be 
included in the block length. 

Variable length records on ASCII tapes 
are specified as format-D. They contain 
the same control information as format-V 
records, but this information is recorded 
in decimal characters. 



gHDEFIMED-FQRHAT (FQRMAT-0) 

Format-0 is provided to permit the proc- 
essing of any blocks that do not conform to 
the F or T formats. Since each block is 
treated as a logical record (unblocked) , 
any deblocking must be done by the user's 
program. 



COHTROL CHARACTER 



FIXED-LEHGTH f FORMAT -F) 

Format-F records are fixed-length. If 
unblocked format F, the logical record con- 
stitutes the block. If blocked format-F 
(applicable to BSAM and QSAM only) , the 
number of logical records within a block 
(blocking factor) is normally constant for 
every block in the data set, unless the 
block is truncated (short block) . 

The system performs physical length 
checking on format-F records, automaticrally 
making allowances for truncated blocks. 



VARIABLE-LEWGTH fFORMAT-V AWD FQRMAT-D) 

Format-? and format-D (ASCII tape only) 
records are variable -length records, each 
of which describes its own length. When 
blocked (applicable to BSAM and QSAM only) , 
each block also includes its block length. 
The system performs length checking of the 
records and blocks. 

The first four characters of the record 
contain control information describing the 
length of the record; the format of this 
information depends on whether the record 
is part of a virtual storage data set or a 
physical seguential data set. 



The user may optionally specify, in the 
DDEF command, the DDEF macro instruction or 
the DCB macro instruction, that a control 
character precedes each logical record in a 
data set, as shown in Figure 23. This con- 
trol character specifies carriage control 
when the data set is printed, or stacker 
selection when the data set is card- 
punched. The character itself is never 
printed or punched, but it is a part of the 
record in storage. 

If the destination of the record is a 
device that does not recognize this control 
character (e.g., disk), the system assumes 
that the control character is the first 
character of data. If the destination of a 
record is a printer or a punch and the user 
has not specified that the first character 
of the record is to be used as a control 
character, this character is simply treated 
as the first character of the data. 



DIAGRAMS OF RECORD FORMATS 

The following pages show the standard 
external record formats for TSS. An exter- 
nal format — the format seen by the user 
— may differ from the internal format. 

• Record formats for virtual seguential 
data sets are shown in Figure 24. 
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• Record formats for virtual index 
segnential data sets are shown in 
Figure 25. 

• Hecxird fomats for physical sequential 
data sets are shown in Figures 26 and 
27. 



firtnal partitioned data sets anst con- 
form to the record formats shown in 
Figure 2ft for virtaal segnential mem- 
bers^ and to those shown in Figure 25 
for virtual index sequential aesbers. 



• Record formats for physical sequential 
data sets on ASCII tapes are described 
in Figures 28 and 29. 



Format F and Formaf U 



Date 



Format V 



4-byte 
length 

ffeld 



Data 



Figure 23. Placement of Control Character in a Record 



Fixed-length 
( Format F) 



Variable-length 
( Format V ) 



Undefined 
(Format U) 



General VSAM 
Rules: 



RECORD 

1 



RECORD 
2 



RECORD 
3 



RECORD 

4 



RECORD 
5 



RECORD 
6 



1 Page 



1 Page 



1 Page 



• Maximum record length; 1 ,048^576 bytes. 

• System automatically keeps track of overlap across page boundaries. 

r^ Record 1 ' ^ | '^ Record 2 ^' | "^ Record 3 ' 



Record 4 



bCfC 



DATA 



bl£l 



DATA 



bUl 



DATA 



b£lt 



DATA 



1 Page 



Page 



I Page 



Maximum record length: 1 ,048,576 bytes. 

System automatically keeps track of overlap across page boundaries. 

User must include length of each variable- length record as first 4 bytes of record; length is specified as bCC£ 
where b contains binary zeros, and C££ contains a binary number specifying length of the record, in bytes. 
This length must include the 4-byte length field. 



Record 1 



Record 2 



Record 3 



Data 


Data 


Data 



] Page 



1 Page 



rage - 



1 Page 



Page- 



Maximum record length: 1 ,048,576 bytes. 

Each record length must be a multiple of 4096 bytes (1 page) in length. If more than one page is required, an 
Integral number of pages is allocated. 

Buffer pages required are supplied by system based on maximum logical record length. 
VSAM data sets cannot be written on volumes containing physical sequential data sets. 



Figure 24. lecord Formats — VSAM 
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Fixed-length 
(Format F) 



Variable-length 
(Format V) 



Initial Key 
-€ RECORD 1- 



RECORD 2 



RECORD 3 



RECORD 4 • 



Key 



DATA 



Key 



DATA 



DATA 



Key 



DATA 



Imbedded Key 



Record I 



Record 2 



Record 3 



Record 4 



First Part 
of Data 



End Part 
of Data 



First Part 
of Data 



End Part 
of Data 



First Part 
of Data 



End Part 
of Data 



First Part 
of Data 



End Part 
of Data 



Initial Key 
^ Record 1 



Record 2 



Record 3 



hm Key 



DATA 



b£ii Key 



DATA 



bCif Key 



DATA 



Imbedded Key 



Record I 



Record 2 



Record 3 



bill 



First Part 
of Data 



End Part 
of Data 



bill 



First Part 
of Data 



End Part 
of Data 



bill 



First Part 
of Data 



End Part 
of Data 



Maximum logical record length; 4000 bytes . 

Maximum number of records jDer data page: 1300. 

Maximum key length: 255 bytes. 

Maximum number of data pages: 65,000. 

Maximum number of overflow pages: 240. 

Maximum number of records per overflow page: 255. 

Maximum number of directory pages: 255. 

User must include length of each variable- length record as first 4 bytes of record; 

length is specified as b£££, where b contains binary zeros, and £££ contains a 

binary number specifying length of the record, in bytes. This length must include 

the 4- byte length field. 

Line Data Set Record 



-^ 




RECORD 




>- 


Record 
Length 


Line 
Number 


Flag 


DATA 


4 


7 


1 




/rl,^*« lc»nrt*k _ I9n kv^foc"^ 




bytes ^ 


bytes 


■* byte ^ 









Maximum record length: 132 bytes. 

Maximum data length: 120 bytes. 

Flog byte indicates whether record originally 

came from terminal keyboard (01) or card reader (00). 



Region Data Set Record 



- RECORD 



Record 
Length 


Region 
Name 


Line 
Number 


Flag 


DATA 



4 

^ bytes 



0-244 
^ bytes - 



7 
h^ bytes - 



^ byte-^^ 



(data length - 244 bytes) 



Maximum record length: 256 bytes. 

Maximum data length: 244 bytes. 

Flag byte indicates whether record originally 

came from terminal keyboard (01) or card reader (00). 



Figure 25. lecord Pormats — flS&E 
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Fixed-length 
(Format- F) 



Fixed-length 
Blocked 
(Format FB) 



Frxed-length, 
Blocked 

Standard Blocking 
(Format FBS) 



I 



RECORD 



RECORD 2 



RECORD 3 



• Moximum record length —32,760 bytes. 

• Each block treated as a logical record. 







- BLOCK 




SHORT 




BLOCK 


^ 










BLOCK 






) 


REC 
1 


REC 
2 


REC 
3 




REC 
4 


REC 
5 




REC 
6 


REC 
7 


REC 
8 ( 



• Maximum block length —32,760 bytes. 

• Blocking factor is usually constant; however, data set may contain truncated or short blocks. 



BLOCK 1 



REC 
1 



REC 
2 



REC 
3 



-BLOCK 2 



REC 
4 



REC 
5 



REC 
6 



■BLOCK 3- 



REC 

7 



REC 



REC 
9 



• Maximum block length —32,760 bytes. 

• Last block may be truncated; truncated block invokes end-of-vo!ume routines. 



Variable-length 
(Format V) 



-LL 



LL^bb 



,iC 



Cl^bb 



DATA 



LL^ 



LL^bb 



£?_, 



rfi2bb 



DATA 



Maximum logical record length — 32,756 bytes. 



Variable-length, 
Blocked 
(Format VB) 



LL^bb 



LL, 



,M, 



£C bb DATA 



£.e. 



ii^bh 



DATA 



LL, 



LL^bb 



£C, 



n^bh 



DATA 



(f 



",bb 
4 



DATA 



• Maximum logical record length —32,763 bytes. 

• Each logical record must describe its own length; this information must be included by user as first 
4 bytes of each record: 

U ii - Binary number specifying record length in bytes. 

bb - Binary Os . 

• System performs length checking of blocks containing Format-V records, based on user-supplied length 
information; when data sets wiHi Format-V records (either blocked or unblocked) are created, 

a 4-byte control block is required In the form LLbb, where: 

LL - Binary number specifying block length in bytes, 
bb - Two bytes reserved for system use . 
Value of LL is determined by adding thejf/sof the records within block and adding 4 bytes for the control field. 

• Format-V and Blocked Format-V records cannot be processed on 7-track tape units without data 
conversion feature. 

Figure 26. lecord Formats — Physical Seguential Data Sets Without Keys 



711 



Undefined 
(Format U) 



RECORD 



RECORD 2 



RECORD 3 



• Maximum record length — 32,767 bytes. 

• Each block Is treated as logical record. 

• No length checking is performed. 

• User must make length of each Format-U record available to system In data set's data control block, 
prior to asking system to write that record . 

• When system reads a Format-U record, it makes record's length available to user in data set's data 
control block . 



Also, there is a device-dependent rule for physical sequential data sets: 



Track-overflow option for direct-access devices; when this option is used, a record that does not fit 
on a track is partially written on that track and continued on nexf track; if this option is not used, 
records are not split between tracks. 



Track overflov» 
(Option T) 



No track 
overflow 



REC 
I 



REC 

2 



REC 
3 



REC 

4 



TRACK 1 



REC 
1 



REC 



REC 
3 



REC 

4 

cont'd 




REC 
5 




REC 
6 


( 


1^ 


TRACK 2 










RECORD 

4 


, 


RECORD 

5 


( 



TRACK 1 



TRACK 2 



Figure 26. Hecori Fornats — Physical Seguential Data Sets Without Keys (cont'd) 
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Key^ 


Data 
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Key^ 


Data 
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Record 
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Record 
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Record 
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Key 


Data 




Key 


Data 


Key 


Data 



Undefined 
(Format U) 



Record — M ^ — Record — H f^ — Record »*J, 

The same rules apply to physical sequential data sets with keys as for those without keys; also: 

• All keys in data set must be the same length. 

• Number of bytes transmitted in a READ or WRITE operation equals the key plus the data portion of record. 
Note: Non-zero KEYLEN operand in DCB Identifies data set with keys. 

Figure 27. lecord Fomats — Physical Sequential Data Sets With Keys 
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Fixed-length, 
Blocked and 
Unblocked 
(Format F) 



Record 1 



Record 2 



Record 3 



!pH!Sr!m!5!!?5|S^^ 



• Maxfmum record length - 32,760 bytes 

• Buffer offset not supported 

• Data in EBCDIC form is translated to ASCII 



Variable-length, 
Unblocked 
(Format D) 



■ 



dddd 



DATA 



dddd 



DATA 



dddd 



DATA 



• Maximum logical record length - 32,756 bytes 

• Block descriptor in example has been stepped over 

• Each logical record must describe its own length; this 
information must be included as first four bytes of each record: 

dddd - unpacked decimal number specifying length in bytes 

• dddd and DATA are translated to ASCII 

• Buffer offset of and 4 are supported 



Variable-length 
Blocked 
(Format DB) 



DDDD 



dddd 



DATA 



dddd 



DATA 



dddd 



DATA^ 



Maximum logical record length - 32,763 bytes 
System performs length checking of blocks containing 
Format-D records, based on user supplied length information; 
when data sets with Format-D records (either blocked or 
unblocked) are created, a 4-byte control block in the form 
DDDD is required, where: 

DDDD - unpacked decimal number specifying block length 
in bytes 
Value of DDDD is determined by adding the dddd's of the 
records within the blocks and adding 4 bytes for the control 
field. 
DDDD, dddd, and DATA are translated to ASCII 



Undefined 

(Format U) 



Record 1 



Record 2 



Record 3 



;™;i;iii;:;lM 



• Maximum record length - 32,767 bytes 

• Each block is treated as a logical record 

• No length checking is performed 

• User must make length of each Format-U record available to 
system in data set's data control block 

• Buffer offset not supported 

• Format U is supported when 128 character set is used 

• Data translated to ASCII 



Note: This represents the output after the system has processed the internal EBCDIC data 
format described in Figure 27. 

Figure 28. Output Record Formats for ASCII Tapes 
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IHDEX 



When More than one page nmmber is iiidi- 
cateiy the aajor reference is first. All 
references are within pins or minns one of 
the indicated page nnnber. 



accessing data sets 16 
accessing privilege 16 
SLCcess Methods 

BSIl - see basic sequential access 

aethod 
lOllQ - see input/ontpnt request 

facility 
MSAM ~ see multiple sequential access 

method 
QSAM — see queued sequential access 

method 
SIM ~ see sequential access methods 
TAMII - see terminal access method 
VIM - see virtual access methods 
fISIH - see virtual index sequential 

access method 
VPAl - see virtual partitioned access 

method 
fSAH - see virtual sequential access 
method 
access, read only 13 
access, read-write 13 
access, restrirting 10 
access, unlimited 13 
aliases 26,27 
assembler interfaces 42 
attach a record to virtual storage 16 
attention interruption (of DATA) 45 
automatic buffering (MSAM) 36 
auxiliary storage 5 



basic sequential access method (BSAH) 23 
buffering 29 
macro instructions: 

BSP 32 

CHECK 32 

CMTHL 32 

DQDECB 32 

FEO¥ 32 

FREES UP 3 1 

FIEBPOOL 31 

GETBOF 31 

GETPOOL 3 1 

HOTE 32 

POINT 32 

BEAD 32 

WRITE 32 
record formats 29 
block count (DCB) 33 
blocking 7 
BSAM 29 
QSAM 33 
buffering, automatic (MSAM) 36 
buffering, BSAM 29 
buffering, double 33 
buffering, exchange 35 
buffering, lOlEQ 38 
buffering, QSAM 35,33 
buffering, single 34 
buffering, ?ISAH 23 



buffering, VPAM 27 

buffering, ¥SAM 18 

build channel programs 39 

bulk input 48 

bulk input/output 48 

bulk output 48 



card input, operator assisted 49 
card reader/punch - see unit record 

equipment 
CATALOG command 50 
catalog, for sharing data sets 13 
catalog, system~use 2 
catalog, user 3 
cataloging, automatic 3 
cataloging data sets 2,49 
cataloging virtual storage data sets 10 
CDD command 8 
CDS command 47 
CCI chaining 36,38 
channel programs (BSAM) 28 
channel programs (SAM) 28 
CHECK macro (BSAH) 28 
CLOSE macro (BSAH) 10,29 
CLOSE macro (QSAH) 34 
CLOSE processing 

SiCCBss method dependent 11 

common 11 
CLOSE, temporary (T) 12 
COMBIN option (DCB) 36 
command chaining 38 
command system interfaces 43 
component 2 
concurrent sharing 13 
COMTEXT command 43 
control blocks 3 

data control block (DCB) 8,10 

data event control block (DECB) 36,38 

data set control block 
(DSCB) 3,17,53-57 

input/output request control block 
(lOlCB) 28 

job file control block (JFCB) 8,9 
control cards (MSAM) 36 
control character 71 
control sections 

public 15 

private 15 
copying data sets 46 
CORRECT command 43 



DATA command 45 
data control block 8 

data event control block (DECB) 36,38 
data group 36 
data management 1 
basic concepts 4 
facilities 1 
data pages 22,23,25 
data set 2 

accessing 16 

cataloging 49 

characteristics 7 

copying 46 

data-card 49 
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lefiBing C^ules) 66 

duplexed 12 

interlock W ,2fi 

introducing to a task 8 

line H2 

list 46 

name 2 

nailing and cataloging 2 

Basing rules 2 

physical sequential 55 

preparing for use 10 

region 43 

sharing 13 

SISIN 49 

virtual partitioned 26 

virtual storage - see virtual storage 
data set 
data set control block (DSCB) 3,17 

formats 54,56 
data set descriptor (DSD) 3,53 
DCB operand of DDBf 9 
DCB, filling in 10 
DCB (see TCT 39) 
BCBICB, field of DCB 37 
DCH (TAMII) 39 
DDEP 8,9 

effeirtive span 9 

suaaary of operands 9,10 
DDNIMB operand of DDEP 9 
deblocking (QSAIf) 33 
delete at close option 12 
DELETE coaaand 50 

device control aodules (TAMII) 39 
device dependencies 39 
direct access volumes 53 
direcrtory, page (VIS AH) 23,25 
directory, partitioned organization 

(POD) 27 
DISP operand of DDEP 10 
DISPLIY, PL/I (P) I/O 52 
double buffering 33 
DSNAHE operand of DDEP 9 
DSOIG operand of DDEP 9 
DUPCLOSE aacro instruction 12 
duplexing option 12 
DDPOPEl aacro instruction 12 
dynaaic loader, use in sharing 15 



EDIT coaaand 43 

edit input/output data 39 

end--of-data routine (EODAD) 20 

ERASE coaaand 4 9 

error processing (MS AM) 37 

error recovery (TAEII) 39,40 

BVV coaaand 50 

EXCEBPT coaaand 44 

exchange buffering 35 

EXCISE coaaand 44 

exit list 41 

external page table (XPT) 18 

external sharing 13,5 



PUD aacro instruction 12,28 
foraat control modules 39 
foraats, record 7,70-76 
POBTIAW interfaces 51 
PORTIAN I/O control 51 
POBTRAl I/O stateaents 51 
POITRAR library 42 
fragmentation, data set 17 
fully gualified data set naae 



GATE aacro instructions 39 


GATRD 


42 


GATWR 


42 


GTMAR 


42 


GTIRC 


42 


GTWSl 


42 


gather— write 38 


generation data group (GDG) 


index 


entry 50 



50,3 



HOLD parameter of DDEP 17 



index entry (generation data group) 50 
index, aaster 3 
indexed data sets 7 
initiate I/O 39 
input, bulk 49 
input/output, bulk 48 
input/output request control block 
(lORCB) 28 

chaining 38 
input/output request facility (lOREQ) 38 

buffering 38 

aacro instructions 
CHECK 38 
lOREQ 38 
?CC1 38 
IISERT coaaand 44 
interfaces 42 

asseabler 42 

croaaand systea 43 

PORTRAH 51 

PL/I (P) 52 
internal sharing 15,13 
interlocks : 

data set 14,24 

aeaber 14,27 

page (¥ISAH) 15,22 

read 14,28 

releasing 15,27 

sharing 14 

write 14,24,28 
INTIMQ aacro instruction 37 



JPCB (see TCT 39) 
job file control block 

filling in 9 
job library 10 



(JPCB) 8 



LABEL operand of DDEP 9 
labels 

trailer (writing) 12 

volume label foraats 53,55,58 
libraries 26 
line control 39 
LIHE? coaaand 46 
line data set 43 
LIST coaaand 44 
list data set 46 
LOCATE coaaand 44 
locators (VISAM) 21 
logical record 7 
LPH 21 



aagnetic tape volumes 

accessing 28 
aain storage 5 
aaster index 3 



57 



78 



MCIST »acro instruction 42 
members 26 
member header 27 
member interlock 14^27 
HODIFY cx>mmana 45 
multiple sequential access method 
(HSAH) 36 
buffering (automatic) 36 
control cards 36 
error processing 37 
macro instructions 
FIWISH 36 
GET 36 
PUT 36 
SITUR 36 
multiple terminal support 40 



naming data sets 2 
HUHBIB command 44 



open processing 10 

common portion 10 

access-metbod-^dependent portion 10 
OPPN 21 

OPTION parameter of DDEF 10 
organization, data set 

indexed 7 

partitioned 7 

physical sequential 28,33,36,55 

sequential 7 

virtual index sequential 21 

virtual sequential 18 
organization, standard tape 57 
output, bulk 48 
overflow page, ?ISAM 21 



23 



17 



2 
7 



PAD parameter (DCB) 

page deletion 25 

page length, reason for choosing 

page interlock 15 

VISAH 24 
partiallf qualified data set name 
partitioned data set organization 
partitioned organization directory 

(POD) 25 
permanent storage 5 
PllHIT command, restriction 13 
physical record 7 

physical sequential data set 55,28,33,36 
PL/I (F) 

DISPLAY I/O 52 

interfaces with data mgmt. 51-52 

SECORD I/O 52 

STREAM I/O 52 
polling 41 
PPN 21 

PRINT command 48 

printer - see unit record equipment 
private storage 5 
privilege, accessing 13 
public storage 5 
public volume table (P¥T) 53 
PUNCH command 48 



queued sequential access method (QSAM) 
blocking 33 
buffering 24-35 
macro instructions 
FEOV 35 



33 



GET 34 
POT 34 
PUTX 35 
RELSB 35 
SETL 34 
TRUIC 35 
record formats 



34 



read interlock 14,28 

restricrtion 1 4 
read-only access 13 
read-write access 13 
real terminal access method 39 
record 2 
record formats, allowable 

BSAH 29 

fixed length 70 

physical sequential data set 70 

QSAH 34 

variable length 70 

fISAM 24,70 

fPAH 70 

VSAM 18,70 

undefined length 70,18 
record , logical 7 
record, physical 7 
RECORD, PL/I (F) I/O 52 
REGIOH command 44 
region data set 43 

REGSIZE parameter (user profile) 44 
relative external storage correspondence 
table (RESTBL) 17 

constructing 18 
RELEASE command 9 
RET parameter (DDEF> 10 
RETPD parameter (DDEF) 9 
retrieval address 18 

VSAH 20 
REVISE command 44 
RT command 49 
RTAM 39 



scatter-read 38 

SECURE command 8 

sequential access methods (SAl) 16,28 

sequential data set organization 7 

shared data set table (SDST) 15 

sharing data sets 13 

catalog use in 13 

concurrent 13 

external 13 

interlocks 14 

internal 15 

virtual storage data sets 14 

VISAH 25 

VPAH 27 

VSAH 20 
single buffering 34 
SPACE parameter (DDEF) 9 
storage, classes of 5 

auxiliary 5 

external 5 

main 5 

permanent 5 

private 5 

public 5 

temporary 5 
STREAM, PL/I (F) I/O 52 
symbolic device address (SDA) 38 
symbolic device allocation table (SDAT) 
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SYS IN data set (aoncoaversational) 49 
systeB operator 48 



tapes p magnetic 59 

acx^essing 28 

organization 59 
TCS {teminal comnand system) 39 
TCT 39 

temporary close (CLOSE (T)) 13 
temporary storage 5 
terminal access method (TAMII) 39 

buffering 43 

error recovery 39 

macros instructions 40 

return codes 41 
terminal control table (TCT) 39 
text editor 43 

creation of VIS data sets 43 
trailer labels ^ writing 12 
translate input data 39 
truncation of data sets 20^22 
TSS mode (BTAE) 42 
TV command 46 



OHIT parameter of DDEF command 
unit record devices 4^36^48 

command system ^ use of 4 

HSAH, use of 36 

users of 4 
unlimited access 13 
BPDAITE irommand 44 
user-data 21 



VAl data set - see virtual storage data set 
virtual access methods (VAM) '^SfM 

procressing data sets 17 
virtual channel command word 38 
virtual index sequential access method 
(VISAM) 20 
buffering 24 
functions 23 
macro instructions 
DELBEC 24 
ISETL 25 



GET 23 
POT 24 
lEAD 24 
lELEX 25 
SETL 23 
WRITE 24 
overflow page 21 
organization (VIS) 43 
page directory 21 
record formats 23 
sharing 24 
truncating 23 
virtual partitioned access method 
(VPAM) 24 

buffering 27 
functions 26 
macro instructions 
FIHD 27 
STOW 27 
organization (VP) 26 
processing 27 
sharing 27 
virtual sequential access method (VSAl) 
buffering 18 
functions 18 
macro instructions 
GST 18 
POT 20 
POTX 20 
SETl 18 
organization 
record formats 
sharing 20 
virtual storage data sets 6 
cataloging 10 
concurrent sharing 13 
virtual terminal support system 39 
VISAM data sets 22-25 
VOLOME operand of DDEP 9 
volume table of contents (VTOC) 55 
VT command 46 
VTSS 39 
VV command 47 



write interlock 14^28 
WT command 49 
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(VS) 18 

18 
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